2015年 5月 11日の投稿一覧

loopbackで作成されたAPIのアクセスコントロールを設定する

の様なモデルのリレーションを定義し、APIも自動的に作成され /rempusers/:id/libraries といった形でアクセスできる様に
なったのですが、ログインして得られるアクセストークンを付与しても現状だと401応答が帰って来ます。

$ http http://localhost:5000/api/RempUsers/55486573fecad3d7215ead80/libraries?access_token=*****
HTTP/1.1 401 Unauthorized
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Sun, 10 May 2015 01:52:10 GMT
ETag: W/"DNoQruYc4EoovuVyGTv+hg=="
Transfer-Encoding: chunked
Vary: Origin, Accept-Encoding
X-Powered-By: Express
{
"error": {
"code": "AUTHORIZATION_REQUIRED",
"message": "Authorization Required",
"name": "Error",
"status": 401,
"statusCode": 401
}
}

これはloopbackで既定されているUserモデルを継承したモデルにはユーザ自身の情報のみが制御できる様なアクセスコントロールが設定されているため、
そのモデルとリレーションするモデルをAPI経由で呼びだそうとすると制限がかけられています。*1

この問題を解消するためのアクセスコントロールを設定します。

loopbackでアクセスコントロールを設定するためのscafoldは slc loopback:acl というコマンドで実現できます。

今回対象となるAPIのエントリポイントはモデルのメソッド的にはgetに対応するためmethod nameとしては __get__libraries を指定します。

$ slc loopback:acl
? Select the model to apply the ACL entry to: RempUser
? Select the ACL scope: A single method
? Enter the method name: __get__libraries
? Select the role: The user owning the object
? Select the permission to apply: Explicitly grant access

具体的にモデル間のリレーションを組んだ時にどの様なメソッドが自動生成したモデルに備わっているかはドキュメントを参照するとわかりやすいです。

アクセスコントロールを設定した後に再度アクセスしてみると、

$ http http://localhost:5000/api/RempUsers/55486573fecad3d7215ead80/libraries?access_token=****
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Length: 329
Content-Type: application/json; charset=utf-8
Date: Sun, 10 May 2015 07:27:01 GMT
ETag: W/"149-11634253"
Vary: Origin, Accept-Encoding
X-Powered-By: Express
[]

今度は問題なく取得できています。

なんとなくloopbackの世界が少しだけ見えてきました。