Server 側での対応概要

Server 側の対応概要

Mobage JS SDK を使って作成したSmartPhone Browser (SPWeb) 向けゲームを、 Shell App SDK を使用して SmartPhone Native アプリケーション化する際に、Server 側でいくつかの対応が必要です。

以下に Server 側で行うべき対応の概要をまとめました。

User Agent による Client ID の使い分け

NBPF では、SPWeb 版と Android アプリ版、iOS アプリ版でそれぞれ Client ID 、Client Secret が異なります。 例えば、アプリケーション ID が 12000129 のアプリの場合、それぞれのClient ID は以下のようになります。

項目

Client ID

SPWeb

12000129-4

iOS アプリ

12000129-8

Android アプリ

12000129-16

 

 また、SPWeb 版と Android アプリ版、iOS アプリ版では UserAgent も異なります。Shell App 内 WebView からの HTTP(S) リクエストは、下記のようになります。

例えば、下記のような UserAgent が送信されます。

  • SPWeb

  • Shell App (Android アプリ)

上記のように、Shell App 内の WebView からは、WebView のDefault User Agent の末尾に、Mobage-ShellApp-SDK-Android といった文字列が付加されます。なお、iOS アプリの場合は、末尾に Mobage-ShellApp-SDK-iOS といった文字列が付加されます。

上記の UserAgent を確認することで、 SPWeb、Android アプリ、iOS アプリの判別を実施し、それぞれに対応した Client ID/Client Secret を利用してください。

Access Token や Refresh Token の区別

Client ID の違いに応じて、Access Token や Refresh Token の権限が異なります。

これにより、下記のように同一ユーザーでも Client ID ごとに Access Token や Refresh Token を使い分ける必要があります。

Game Server から Batch 処理で API を利用する際など、user_id, client_id ごとに 異なる Access Token、Refresh Token が管理されていないと実行できない処理があるため、user_id、 client_id の組み合わせごとに Access Token、Refresh Token を管理してください。

 

更新履歴

  • 2015/02/05
    • 新規作成

 

 

 

PREVIOUS

Client 側での対応概要

NEXT

Shell App SDK アプリケーション開発の流れ