mBaaSでは同一IDからのログインがあった場合、後からのログインが優先されます。セッションはユーザにつき一つであり、新しいログインがあると上書きされる仕組みです。この仕組みの場合、以下のメリットがあります。
古い端末でログアウト処理していなくとも大丈夫
もし古いセッションが優先される場合、過去にログインした端末でログアウトしなければ新しい端末で使えないという問題が発生します。手元にある端末であれば問題ありませんが、離れた場所にあったりすると大きな問題になります。
データ量の抑制
もし複数端末で同時ログインできるようになると、その分管理するデータ量が増加します。mBaaSは全ユーザでリソースを共有するタイプのサービスなので、データ量が増加することによって認証処理を伴った保存処理やデータ検索処理などが重たくなってしまう可能性があります。
1ユーザ1セッションにすることで、データ構造をシンプルにし、データ量が増えるのを防げるようになります。
しかし、問題もあります。
別な端末で突然ログアウト扱いになってしまう
通常の管理方法をとっている限りでは問題ありませんが、IDとパスワードを共有している場合は自分の気付かないタイミングでmBaaSからログアウトしてしまっている可能性があります。基本的にはID/パスワードを共有しなければ発生しない問題ではあります。
複数端末でデータを共有しづらい
ノートアプリなどでスマートフォン側で保存したデータを即時タブレットなどに反映したいと考えた場合に複数端末での同時ログイン機能が欲しくなるでしょう。
ちょっと強引な方法として、ロールを使った方法が考えられます。手順としては次のようになります。
- ログインIDに何らかの端末毎の名称をつける（例えばuser001がiPhone7で新規登録したらuser001_iPhone7とします）
- ユーザ作成時に user001 でロールを作成し、その中にuser001とuser001_iPhone7を所属させます。
- 別な端末（例えばNexus7）も同様にuser001_Nexus7などとします。user001_Nexus7がいない場合は認証はuser001について行って問題ないことを確認し、その上で新しいユーザとしてuser001_Nexus7を作成します。
- 通常時はuser001_iPhone7やuser001_Nexus7でログインします。
データの権限はロールとしてのuser001で行うことで全端末からアクセスできるようになります。しかしロールをあまり増やすとデータストアへの負荷が大きくなります。そのためお勧めしない方法になります。
また、もう一つのやり方としてスクリプトを利用する方法が考えられます。手順としては次のようになります。
- IDとパスワードをスクリプトへ送り、スクリプトで認証を行う
- 認証が通ったら、セッションIDをIDとパスワードから生成したハッシュとともにデータストアに保存
- スクリプト側では常に最初にハッシュをチェックし、すでにそのハッシュでデータがあればobjectIdを返却する
- アプリから保存や認証情報が必要な際には取得したobjectIdを送信してスクリプト側でセッションIDと交換してからデータの保存、取得を行う
このようにセッションIDをデータストア側に保存し、その代わりに該当セッションIDを保存したobjectIdを複数端末で扱うようにします。問題点としては通常データを保存するだけ（1アクセス）が、スクリプト呼び出し/objectIdとセッションIDの交換/データの保存と3アクセスになってしまうことでしょう。
逆にすでにログインしていた場合、他の端末からアクセスを防ぐ目的でも上記方法は利用できます。
- 初回ログイン時にセッション有効期限（デフォルトで24時間）とID、パスワードのハッシュをデータストアに保存
- 他の端末ではログイン時にID/パスワードのハッシュを使って有効なセッションデータが存在するかチェック
- あればログイン不可、なければログイン処理をしてセッション有効期限を保存
- ログアウト処理時には上記クラスからデータを削除
といった方法です。ただしこの場合の難点として、有効期限がmBaaSへアクセスする度に更新しなければならないということでしょう。更新しないとログインしてから24時間でセッションが切れた扱いになってしまい、認証情報が上書きされてしまいます。つまりログイン後のmBaaSへのアクセスは常にAPIを2倍消費してしまうようになります。
明確な指針はないのですが、mBaaSとしては後からログインした端末を有効とする作りになっています。アプリ側でも擬似的に同時ログインを防いだり、ログインで上書きされても安全な作りにしておく必要があるでしょう。