プログラム

loopbackでAPIのテストを書く際にloopback-testingを利用してAPIのテストを書いてみたのでその際のメモ。

まずは必要なnpmパッケージをloopbackアプリケーションに導入します。loopbackアプリのルートで以下のnpmコマンドを実行。

www.npmjs.com

$ npm install loopback-testing --save-dev
$ npm install chai --save-dev

これで準備完了。加えて npm test でテストを実行できる様に package.json 内のscriptsの定義を以下の様に書き換えます。*1

"scripts": {
"test": "NODE_ENV=\"testing\" ./node_modules/loopback-testing/node_modules/.bin/mocha -R spec --recursive"
}

上記の意図は npm test が実行された際に testing 環境としてnode_modules配下のmochaを利用してテストを実行します。

それにともなってtesting環境でloopbackアプリが実行された際のデータソース(DB接続先)を定義しておきます。Circle CI等のCI環境でもすぐに実行できる様に、memoryを指定します。

~/server/datasources.testing.js というファイルを用意して以下の様にデータの保存先をmemoryに指定します。

module.exports = {
db: {
connector: "memory",
defaultForType: "db"
}
};

これでテストが実行できる様になりました。expressの流儀と同様にプロジェクト直下の test ディレクトリに現在開発しているloopbackアプリケーション(API)のテストを書いてみます。

例えばユーザ登録(メールアドレスとPWをPOSTするとユーザ登録できる)のAPIのテストであれば、

var lt = require('loopback-testing');
var chai = require('chai');
var assert = chai.assert;
var app = require('../../server/server.js');
describe('/api/users', function() {
var newUser = {email: "tester1@remp.jp", password:"tester1remp"};
describe('ユーザ登録', function() {
lt.describe.whenCalledRemotely('POST', '/api/users', {}, function() {
it('ユーザ登録の際にメールアドレス、パスワードのパラメータは必須', function() {
var codes = this.res.body.error.details.codes;
assert.include(codes.password, 'presence');
assert.include(codes.email, 'presence');
assert.include(codes.email, 'format.null');
});
});
lt.describe.whenCalledRemotely('POST', '/api/users', newUser, function() {
it('メールアドレス, パスワードを与えるとユーザ作成できる', function() {
assert.equal(this.res.statusCode, 200);
});
});
});
});

といった具合に記述することができます。

ほぼコードを読んだままなのですが、 lt.describe.whenCalledRemotely の記述で指定のエントリポイント下へ指定のメソッド及びパラメータでアクセスがあった場合のテストを書くことができます。

また、アクセスするユーザにロールや状態をもたせた状態のテストも同様に記述ができ、例えばログインを行ったユーザによるAPIへのアクセスを想定したテストは

  var user = {
id: 2,
email: "tester2@remp.jp",
username: "tester2",
password: "tester2remp"
};
// (snip)
describe('ユーザによるプレイリスト操作', function() {
lt.describe.whenCalledRemotely('GET', '/api/users/2/playlists', function() {
it('未ログインユーザはユーザのプレイリストは取得できない', function() {
assert.equal(this.res.statusCode, 401);
});
});
lt.describe.whenCalledByUser(user, 'GET', '/api/users/2/playlists', function() {
it('ログインしたユーザ自身のプレイリストは取得できる', function() {
assert.equal(this.res.statusCode, 200);
});
});
});

の様に lt.describe.whenCalledByUser という記述で実現することができます。他にも各種ロールを割り当てた上での記述が行える様になっています。

こういった形でテストを用意した上で npm test で実行してみると...

といった具合にmochaによるテストが実行できています。

loopbackで作成したAPIであれば、loopback-testingを用いることでアクセスするユーザの各種ロールを想定したテストが記述できて便利ですというお話でした。

まとめ

• loopbackアプリケーションでのテストを行うために loopback-testing を導入しました
• npm test でテストを実行できる様にpackage.jsonの一部を修正しました
• whenCalledRemotely, whenCalledByUser 等 loopback-testingを利用することで用意に各種ロールを想定したテストが書けました

あわせて読みたい

• loopbackでアプリケーションを作成してユーザ登録APIを作るまで - テノニッキ (@hideack 's diary)
• loopbackでMongoDBを利用する - テノニッキ (@hideack 's diary)
• loopbackでAPIにアクセスした際のACLの適用状況を確認する - テノニッキ (@hideack 's diary)
• loopbackでモデルのrelationを定義する - テノニッキ (@hideack 's diary)
• loopbackで作成されたAPIのアクセスコントロールを設定する - テノニッキ (@hideack 's diary)
• strong-pmを稼働させてloopbackアプリをデプロイする - テノニッキ (@hideack 's diary)

の様なモデルのリレーションを定義し、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の世界が少しだけ見えてきました。

参照

docs.strongloop.com

 

4 Pockets

LoopBack Documentation | LoopBack Documentation

http://docs.strongloop.com/display/public/LB/Accessing+related+models

LoopBack is a highly-extensible, open-source Node.js framework that enables you to create dynamic end-to-end REST APIs with little or no coding.

loopbackでモデルを作成するときslcコマンドで作成できるのだけど、
モデル間のリレーションを同様にscafoldするやり方のメモです。

ここでは1対多となるモデルのリレーションの定義をslcコマンドで行ってみます。
例としてRempUserというユーザが複数のプレイリストを持つケースを想定します。

ユーザのモデルは既に作成されているものとして、プレイリストを管理するモデルを復習がてら作成します。

$ slc loopback:model
? Enter the model name: Playlist
? Select the data-source to attach Playlist to: db (mongodb)
? Select model's base class: PersistedModel
? Expose Playlist via the REST API? Yes
? Custom plural form (used to build REST URL):
Let's add some Playlist properties now.
Enter an empty property name when done.
? Property name: title
invoke   loopback:property
? Property type: string
? Required? Yes
Let's add another Playlist property.
Enter an empty property name when done.
? Property name: published
invoke   loopback:property
? Property type: boolean
? Required? Yes
Let's add another Playlist property.
Enter an empty property name when done.
? Property name:

次に先ほど作成したプレイリストのモデルとユーザモデルの間のリレーションを定義します。

これもscafoldできて slc loopback:relation というコマンドで実現できます。

$ slc loopback:relation
? Select the model to create the relationship from: RempUser
? Relation type: has many
? Choose a model to create a relationship with: playlist
? Enter the property name for the relation: playlists
? Optionally enter a custom foreign key:
? Require a through model? No
$ slc loopback:relation
? Select the model to create the relationship from: playlist
? Relation type: belongs to
? Choose a model to create a relationship with: RempUser
? Enter the property name for the relation: RempUser
? Optionally enter a custom foreign key:

このコマンドで具体的に行われるのは common/models/*.json で保管されている各モデルの定義が記載されているJSON中 relations という
要素に定義が追加されます。

実際に該当のJSONファイルを見てみると、例えばユーザモデルであれば、

{
"name": "RempUser",
"base": "User",
"idInjection": true,
"options": {
"validateUpsert": true
},
"properties": {},
"validations": [],
"relations": {
"playlists": {
"type": "hasMany",
"model": "Playlist",
"foreignKey": ""
}
},
"acls": [],
"methods": []
}

といった具合にプレイリストモデルとのリレーションの定義が追加されていることがわかります。

また、loopbackの特徴であるモデル定義がそのままAPIとして反映されているので、loopbackのAPI Explorerを介して該当モデルの
エントリポイントを確認してみると、

といった形でCRUDできるAPIが作られています。便利。

ただ、今回の例の場合、新しく作成されている /RempUsers/:id/playlists といったエントリポイントにアクセスをしても HTTP/1.1 401 Unauthorized となってしまいます。

これは、loopbackで設けられているAPIに対するアクセスコントロールによるものなのですが、この辺りを解決するやり方はまた次回。

参考

strongloop.com

 

1 User

45 Pockets

StrongLoop - Defining and Mapping Data Relations with LoopBack Connected Models

https://strongloop.com/strongblog/defining-and-mapping-data-relations-with-loopback-connected-models/

loopbackで作成したAPIには、ユーザのロールに応じてアクセスコントロールを指定することができます。

docs.strongloop.com

 

251 Pockets

LoopBack Documentation | LoopBack Documentation

http://docs.strongloop.com/display/public/LB/Controlling+data+access

LoopBack is a highly-extensible, open-source Node.js framework that enables you to create dynamic end-to-end REST APIs with little or no coding.

例えば、

• adminユーザのみアクセス可
• このロールのユーザのみアクセス可
• 認証済のユーザであればアクセス可

といった様なアクセスコントロールをslcコマンドでscaffoldすることができます。(やっていることはmodelの定義をしているJSONにアクセス権限の設定を付与している)

この設定を簡単にチェックするためにアプリケーションログとして標準出力するにはloopbackアプリケーション指定時に以下の環境変数を指定することで実現できます。

$ DEBUG=loopback:security:acl slc run

といった形でloopbackアプリを起動するとloobackで作成したAPIにアクセスした際にそのAPIへ適用されているアクセスコントロールの適用状況を確認することができます。

例えば RempUser というモデルがあり、/api/RempUsers/{id} というエントリポイントに対してユーザ情報を取得するためGETリクエストを発行した場合、発行と同時にアクセスコントロールの適用状況がログとして標準出力に出力されます。

$ http http://localhost:5000/api/RempUsers/1?access_token=pIIxAUP6qn2OtXntEGWO6KxAU71qDSS14A1qZamwTTk2xZEOppdtUVRM3agrdoQ8

といった形でリクエストを発行すると、以下の様なログが出力されます。

loopback:security:acl The following ACLs were searched:
loopback:security:acl ---ACL---
loopback:security:acl model RempUser
loopback:security:acl property findById
loopback:security:acl principalType ROLE
loopback:security:acl principalId $owner
loopback:security:acl accessType *
loopback:security:acl permission ALLOW
loopback:security:acl with score: 8016
loopback:security:acl ---ACL---
loopback:security:acl model RempUser
loopback:security:acl property *
loopback:security:acl principalType ROLE
loopback:security:acl principalId $everyone
loopback:security:acl accessType *
loopback:security:acl permission DENY
loopback:security:acl with score: 7495
loopback:security:acl ---Resolved---

この出力を確認することでloopbackが該当のエントリポイントに対してどういった判断が行われてアクセス可/不可の判定を行ったか確認することができます。

loopbackでアプリケーションを作成した直後はデータストレージにmemoryが設定されているため、そのままだとアプリケーションが再起動するたびにmodelの内容が初期化されてしまうため、保管できる様にMongoDB*1を利用できる様にします。

作成したアプリケーションルートでnpmコマンドを叩きます。

$ npm install loopback-connector-mongodb --save

www.npmjs.com

MongoDBに接続するためのコネクタがpackage.jsonに追加されて必要なnpmモジュールがインストールされたのを確認した後、server/datasource.json にある
データベースへの接続設定を更新します。

{
"db": {
"name": "db",
"connector": "mongodb",
"host": "127.0.0.1",
"database": "hogehoge_development",
"username": "",
"password": "",
"port": 27017
}
}

必要な設定はこれだけになります。

先日作成したユーザ登録のAPIを呼び出してみます。

☁  http POST http://0.0.0.0:3000/api/users password=hogehoge email=hideack@remp.jp
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Length: 59
Content-Type: application/json; charset=utf-8
Date: Mon, 04 May 2015 06:30:46 GMT
ETag: W/"3b-84c0720e"
Vary: Origin, Accept-Encoding
X-Powered-By: Express
{
"email": "hideack@remp.jp",
"id": "554712159967a7b3efce0f0c"
}

MongoDBで永続化されているかを確認してみます。

素朴に mongo コマンドでMongoDBに接続して確認します。

> show collections
User
system.indexes
> db.User.find()
{ "_id" : ObjectId("554712159967a7b3efce0f0c"), "password" : "$2a$10$AzdK8q7nUIHxcoiW5y17Lusb4eag7VOjwQI.e5ukjJRWKMWXSaP6a", "email" : "hideack@remp.jp" }
>

loopbackで作成したアプリケーションで操作されたmodelの内容がMongoDBで永続化される様になりました。

併せて読みたい

• MongoDB connector - LoopBack - Documentation

過去のloopbackに関する記事

• loopbackでアプリケーションを作成してユーザ登録APIを作るまで

StrongLoopが開発したloopbackは、Node.jsで作られたフレームワーク(所謂mBaaSのオープンソース実装)で以下の様な特徴があります。

• RESTなAPIをモデルと対応させて素早く作れる (モデルを作るとCRUDするAPIが出来上がる)
• モデルはコネクタを介して様々なDBで永続化できる
• API自体は application/json なAPIとして操作でき、各種クライアント向けのSDKを備えている

といった特徴があります。

利用実績としては、GoDaddyでpublic reseller APIに利用されている様です。

strongloop.com

 

8 Pockets

StrongLoop - Page Not Found

https://strongloop.com/strongblog/godaddy-api-platform/

SPAなアプリケーションを2011年からREMPやSTOBO、
そしてRendrを利用してCastoを作ってきましたが、もしかしたらloopbackを使ってAPI開発をよりスムーズに
解決できるのではないか。という期待を抱きつつ試しに触ってみました。

ひとまずゴールとしては、

loopbackでアプリケーションを作成し、APIを介してユーザを作るところまで

とします。

準備

とにもかくにも strongloop コマンドをインストール。*1

$ npm install -g strongloop

これで slc コマンドが使える様になってscaffoldできます。

アプリケーション作成

実際にアプリケーションを作成してみます。(謎のキャラクターが表示されます)

☁  slc loopback remp-api
_-----_
|       |    .--------------------------.
|--(o)--|    |  Let's create a LoopBack |
`---------´   |       application!       |
( _´U`_ )    '--------------------------'
/___A___\
|  ~  |
__'.___.'__
´   `  |° ´ Y `
? What's the name of your application? remp-api
? Enter name of the directory to contain the project: remp-api
create remp-api/
info change the working directory to remp-api
Generating .yo-rc.json
I'm all done. Running npm install for you to install the required dependencies. If this fails, try running the command yourself.
create .editorconfig
create .jshintignore
create .jshintrc
create README.md
(snip)
Next steps:
Change directory to your app
$ cd remp-api
Create a model in your app
$ slc loopback:model
Optional: Enable StrongOps monitoring
$ slc strongops
Run the app
$ slc run .

ユーザーモデルを作成

続いてユーザーを管理するためのモデルを作成してみます。

loopbackではいくつかのbase classが用意されていてその中にUserというクラスが存在するので今回はこれをこのまま利用します。

基本的なユーザ管理をする場合であればbase classのままでよいのですが、何か新たにプロパティ足したい場合は追加をすることもできます。今回はスキップ。

☁  slc loopback:model
? Enter the model name: user
? Select the data-source to attach user to: db (memory)
? Select model's base class: User
? Expose user via the REST API? Yes
? Custom plural form (used to build REST URL):
Let's add some user properties now.
Enter an empty property name when done.
? Property name:
☁  

上の操作で以下の様な要素を持ったユーザ管理のモデルが作成できます。

APIを呼び出してみる

では、モデルを作成 = API作成 ができたので実際にHTTPクライアントからAPIを呼び出してみます。

loopbackアプリケーションを起動します。

☁  node .
Browse your REST API at http://0.0.0.0:3000/explorer
Web server listening at: http://0.0.0.0:3000/

おもむろにloopbackアプリケーションを呼び出します。

先ほど作成したUserモデルに対応するAPIのエントリポイントは /api/users に対応しますので、そこへメールアドレスとパスワードをPOSTします。

☁  http -v POST http://0.0.0.0:3000/api/users password=hogehoge email=hideack@remp.jp
POST /api/users HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Content-Length: 52
Content-Type: application/json; charset=utf-8
Host: 0.0.0.0:3000
User-Agent: HTTPie/0.8.0
{
"email": "hideack@remp.jp",
"password": "hogehoge"
}
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Length: 34
Content-Type: application/json; charset=utf-8
Date: Sat, 02 May 2015 05:27:48 GMT
ETag: W/"22-3085cb67"
Vary: Origin, Accept-Encoding
X-Powered-By: Express
{
"email": "hideack@remp.jp",
"id": 2
}

ステータスコード200が帰って来てユーザを作成することができました。

ログインしてみる

では、先ほど作成したユーザでログインしてみます。ユーザ作成の際に利用したメールアドレスとパスワードを要素としてPOSTします。

ログイン用のエントリポイントは /api/users/login なので、ここにユーザ登録の際に設定したメールアドレスとパスワードを渡します。

☁  http -v POST http://0.0.0.0:3000/api/users/login email=hideack@remp.jp password=hogehoge
POST /api/users/login HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Content-Length: 52
Content-Type: application/json; charset=utf-8
Host: 0.0.0.0:3000
User-Agent: HTTPie/0.8.0
{
"email": "hideack@remp.jp",
"password": "hogehoge"
}
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Length: 135
Content-Type: application/json; charset=utf-8
Date: Sat, 02 May 2015 05:30:16 GMT
ETag: W/"87-4fc8ab24"
Vary: Origin, Accept-Encoding
X-Powered-By: Express
{
"created": "2015-05-02T05:30:16.742Z",
"id": "r3YFqmceF1INk5FlstmZgO7p2y42TyLYPlzSchPIDIDBlAbuOHQurS5j5gOSH82h",
"ttl": 1209600,
"userId": 2
}

ステータスコード200が帰って来て、API操作用のトークンが戻ってきました。なお、パスワードが誤ると、

HTTP/1.1 401 Unauthorized
{
"error": {
"code": "LOGIN_FAILED",
"message": "login failed",
"name": "Error",
"stack": "Error: login fail...",
"status": 401,
"statusCode": 401
}
}

となって期待通りです。

ログイン時のトークンを利用してユーザ情報を取る

続けて先ほどログイン時に取得したトークンを利用してユーザの情報を取得してみます。

現状だとUserモデルしか存在しないのでできることが少ないですがログインしているユーザ自身の情報を取ってみます。

/api/users/2?access_token=(ログイン時に得たtoken) に対してGETします。

☁  ~  http http://0.0.0.0:3000/api/users/2\?access_token\=r3YFqmceF1INk5FlstmZgO7p2y42TyLYPlzSchPIDIDBlAbuOHQurS5j5gOSH82h
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Length: 34
Content-Type: application/json; charset=utf-8
Date: Sat, 02 May 2015 05:45:01 GMT
ETag: W/"22-3085cb67"
Vary: Origin, Accept-Encoding
X-Powered-By: Express
{
"email": "hideack@remp.jp",
"id": 2
}

scafoldする際に特にプロパティを追加していないのでidとemailのみ返ります。

API Explorer

ここまでコマンドラインのHTTPクライアントでAPIを操作してみましたが、実はscafoldした時点でStrong Loop API ExplorerというWebアプリが同時に起動しています。

http://0.0.0.0:3000/explorer

へブラウザでアクセスすると以下の様な画面を閲覧できて実際にAPI操作も行うことができます。

まとめ

loopbackを利用して、アプリケーションの作成とユーザを管理するモデルの作成(それと同時にユーザ操作をするAPIの作成)を行ってみました。

気づかれたかもしれませんが、上までの操作だとモデルを保管する先のストレージを何も設定していない状態なのでアプリケーションの再起動で全て消えます...。

データベースの接続はまた次の機会に。