ニフティクラウド mobile backendのJavaScript SDKが9月にバージョンアップしたのに伴い、主に会員管理周りの使い勝手が結構変わったので、簡単にまとめてみました。

ニフティクラウド mobile backend→http://mb.cloud.nifty.com/

主な変更点

複数会員のログイン状態を保持できるようになった/セッショントークンを効率的に使いまわせるようになった
SNS連携でパラメータを直接自分で設定するようになった
Node.jsで書かれているので、サーバサイドで使いやすくなった

複数会員管理については、インスタンスにセッショントークンを保持しておいて、それを適宜切り替えることで、ユーザを切り替える際に毎回APIリクエストをする必要がなくなりました。詳しくは次項でログインの仕組みと併せて書きます。

SNS連携についてはこちらに記載があります。
v1ではログインに必要な情報（トークンや有効期限）の取得からすべて一括でやってくれていましたが、FaceBookやTwitterの仕様変更が頻繁で、そのたびにSDKのバージョンアップを待たないとSNSログイン機能が使えないという問題がありました。
今回の変更で、自分で実装する部分は若干増えましたが、仕様変更にすばやく対応できるようになりました。
設定するパラメータについては、APIの仕様についてのページに書かれています。

また、Node.jsで書かれているので、サーバサイドでも直接RestAPIを叩かずにmBaaSにアクセスできるようになりました。
これにより、mBaaSとアプリの間にサーバを用意して、自前の会員情報とmBaaSを連携させてログインを管理したり、mBaaSの会員情報と課金情報を組み合わせてガチャの管理やチートの監視をするといった使い方も以前より簡単にできるようになりました。（具体的な実装方法については詳しくわかりませんが…。）

ログインの仕組み

そもそもログインしているというのはどういう状態なのか？という点について簡単に説明します。
特定のユーザーとしてACLにしたがってデータにアクセスできる条件は大まかに２つあり、
1. システムからセッショントークンが払い出されている
2. そのセッショントークンをリクエストヘッダーに設定してリクエストしている
ことです。
ここでは便宜上1を「システムログイン」、2を「アクティブログイン」と呼びことにします。

システムログインをするためにはAPIリクエストが必要になります。
セッショントークンを取得できるリクエストは「会員登録API」と「会員ログインAPI」です。
これらのリクエストを行なうことで、システム上でセッショントークンが生成され、レスポンスで取得することができます。
セッショントークンには有効期限があり、デフォルトでは24時間で期限切れになります。（コンパネで変更できます。）
また、「会員ログアウト」のリクエストを行なうことで明示的にセッショントークンを破棄することもできます。
セッショントークンは複数の会員に対して生成・払い出しが可能で、それぞれが独立したものとして扱われます。有効期限も個別に設定されます。

しかし、セッショントークンが払いだされただけでは、そのユーザーとしてデータにアクセスすることはできません。そこで、ヘッダーへのセッショントークンの設定が必要になります。これはSDK側で行ないます。
つまり、A,B,Cの3ユーザーにセッショントークンに払いだされている場合、いずれかのセッショントークンをヘッダーに設定してアクティブログイン状態にします。この状態でリクエストを送ると、そのユーザーの権限でデータにアクセスできます。このとき、アクティブログイン状態にできるのは１人だけで、複数人のセッショントークンを一度に設定することはできません。

v1とv2でどう変わったのか

v1ではセッショントークンを取得するリクエストが発生した場合、必ずそれをヘッダーに設定するようになっていました。つまり、システムログインとアクティブログインが一連の処理として扱われていました。
一方、v2ではシステムログインとアクティブログインが基本的に分離されていて、login系のクラスメソッドでのみアクティブログインを行います。つまり、signUp系およびlogin系のインスタンスメソッドはシステムログインのみを行ないます。
何故このような作りになっているかというと、複数のセッショントークンを取り回す際のAPIリクエストの効率化のためです。

v1ではアクティブログインをする際に毎回リクエストを送るため、ユーザーを切り替えるたびにAPIリクエストが発生していました。しかし、先ほど書いたとおりセッショントークンは有効期限があり、それまでなら再利用が可能なので、まだ生きているセッショントークンがあるのに毎回新しいセッショントークンを生成するのは非効率でした。
v2では初回のリクエストで生成されたセッショントークンをそれぞれのUserインスタンスで保持しておき、手元でそれらをヘッダーに付け替えることで、リクエストなしでアクティブログインしているユーザーを切り替えることができます。

また、login系のメソッドではシステムログインのリクエストを行なうかをセッショントークンの有無で判断するので、login系のクラスメソッドを実行した場合、既にセッショントークンを持っていればヘッダーの付け替えのみを行い、セッショントークンがなければシステムログインのリクエストを行なったあとで、ヘッダーへの登録を行ないます。

CurrentUserについて

アクティブログインしているユーザーは「CurrentUser」としてローカルの保存領域に情報が保持されます。
これにより、画面遷移やアプリの終了などで手元のログイン情報が失われてしまった場合でも、getCurrentUserメソッドによってアクティブログインしていたユーザーの情報とセッショントークンを取得することができます。
CurrentUserの情報を破棄するにはlogoutのクラスメソッドを実行します。（同時にセッショントークンも無効になります。）

注意点

v2では複数会員のログインの取り扱いが可能になった反面、オペレーションが複雑になりました。
特に以下のようなはまりやすい点がいくつかあるので、注意してください。

signUpの段階ではセッションログイン状態にはならなくなった。
→signUpが完了したタイミングでloginを行なう必要がある。
（signUpの時点でセッショントークンは取得済みなので、APIリクエストは消費されません。）
　
セッショントークンが期限切れになったときは、loginする前に一度logoutする必要がある。
→インスタンスにsessionTokenフィールドがあるかどうかでloginのリクエストを行なうか判断されるので、期限切れでもsessionTokenを保持していると、更新のリクエストがされない。
logoutを行なうことで、セッショントークンのリセットとフィールドの削除が行なわれるので、再度loginする際に更新のリクエストが発生するようになります。
※クラスメソッドだけでなくインスタンスメソッドでも同様です。

まとめ

ログインの仕組みをからめてv1とv2の構造の違いについてまとめました。
ただ、複数のユーザー情報を取り回す場面はアプリ（フロント）側ではあまりないと思います。
そんなときは基本的にクラスメソッドを使っておけば問題ないです。
あとは注意点に書いた２点にひっかからなければv1と同じような使い方ができると思います。

今回は以上です。

ーー
ニフティクラウド mobile backend：http://mb.cloud.nifty.com/

ーー