![画像](https://habrastorage.org/storage2/678/d65/49e/678d6549efdce008178c444bcc3b0587.png)
今日は、 QuickBloxの認証方法について説明します。 承認とその側面に影響を与えます。
そのため、 QuickBlox APIへのリクエストにはtokenを添付する必要があります 。 認可リクエスト自体以外。 QuickBloxには4つの許可エンティティーがあります。
- アプリ
- ユーザー
- デバイス
- デバイスユーザー
アプリケーションは、読み取り専用特権を持つエンティティです。 たとえば、 アプリケーショントークンを使用すると、評価や場所へのリクエストなど、多くの情報リクエストを実行できます。 アプリケーショントークンで使用できる書き込み操作は、ユーザーの作成のみです。 このエンティティは、次のデータセットで認証されます。
- アプリケーションID
- 認証キー
- 認可の秘密
このデータセットは、すべてのエンティティの認証の標準であり、アプリケーション設定で確認できます。
![画像](http://image.quickblox.com/09a8d8925fb752c577bb1d730b1e.injoit.png)
ユーザーとは、プッシュメッセージを受信するための登録など、おそらくデバイスに関連する操作を除き、APIを使用してすべてのタイプの操作にアクセスできるエンティティです。 ユーザーは アプリケーションと同じ方法で認証されますが 、フィールドに追加されます
- ユーザー[ログイン]
- ユーザー[パスワード]
- ユーザー[owner_id]
デバイスはアプリケーションと似ていないエンティティです 。 同じことを書く権利はありません 。 唯一の違いは、アプリケーションがインストールされているデバイスを追跡する機能です。 エンティティデバイスはアプリケーションフィールドに追加します
- デバイス[監査]
- デバイス[プラットフォーム]
デバイスのユーザーは、 QuickBlox APIで可能なすべての操作を使用できる主要な許可エンティティです 。 認証には、前述のすべての段落が使用されます。
そして、 トークン生成について詳しく説明します 。 トークンキーは、 http: //api.quickblox.com/sessionで次のフィールドを使用したリクエストによるPOST認証リクエストに応じて、 QuickBloxの腸内で生成されます。
アプリ | |
application_id | アプリケーションID |
auth_key | アプリケーションキー |
タイムスタンプ | Unix時代の形式の時間。サーバーの時間と1時間異なる場合があります。 |
一回だけ | 乱数 |
署名 | 署名 |
ユーザー | |
ユーザー[ログイン] | ユーザーログイン |
ユーザー[パスワード] | ユーザーパスワード |
ユーザー[owner_id] | ユーザーの所有者。 2012年5月30日から、このフィールドは受け入れられますが、無視されます。 省略できます。 |
装置 | |
デバイス[プラットフォーム] | デバイスプラットフォーム-iOS、Android、またはWindows_Phone |
デバイス[監査] | 一意のデバイス識別子 |
アプリケーションユーザーは、説明されているすべてのPOSTフィールドを使用します。
署名の形成に関する詳細をお読みください。 署名は、 HMAC-SHA1メカニズムを使用して暗号化されます。 暗号化本体として、POSTリクエストフィールドの文字列がGETリクエストとして使用されます。 フィールドはアンパサッドで区切られます。 フィールドもアルファベット順にソートされます。 暗号化キーは、前述の認証シークレットです。
PHPで署名を作成する例:
$body="application_id=$app_id&auth_key=$auth_key&device[platform]=$device_platform&device[udid]=$device_udid&nonce=$nonce×tamp=$timestamp&user[login]=$user_login&user[owner_id]=$owner_id&user[password]=$user_password"; $signature=hash_hmac('sha1',$body,$auth_secret);
ここで、より便利なものを見ることができます: http : //pastebin.com/FhS5YEqR
セッションを作成するときに、セッションに関する情報が提供されます。 デフォルトの形式はXMLです。 ただし、終了URI「.json」で指定すると、答えはJSON形式になります。
ユーザー認証リクエストの例を次に示します 。
curl -X POST -H "Content-Type: application/json" -d '{"application_id": "2", "auth_key": "DtF9cZPqTF8Wy9Q", "timestamp": "1333630580", "nonce": "1340569516", "signature": "13293a5bd2026b957ebbb36c89d9649aae9e5503", "user": {"login": "injoit", "password": "injoit", "owner_id": "4"}}' https://api.quickblox.com/auth.json
以下は、 ユーザー認証要求への応答の例です。
{ "session": { "application_id": 2, "created_at": "2012-04-03T07:41:12Z", "device_id": null, "id": 744, "nonce": 289239351, "token": "25b29b8c8d6f2d3afbf1d437cc611b23741fc7ee", "ts": 1333438822, "updated_at": "2012-04-03T07:41:13Z", "user_id": 3 }
また、たとえば、 ユーザーでログインしてアプリケーショントークンをアップグレードできます。
curl -X POST -H "Content-Type: application/json" -d '{"login": "injoit", "password": "injoit", "owner_id": "4", "token": "cf5709d6013fdb7a6787fbeb8340afed8aec4c69"}' http://api.quickblox.com/login.json { "blob_id": null, "created_at": "2012-01-16T08:13:38Z", "custom_parameters": null, "email": null, "external_user_id": 111, "facebook_id": null, "full_name": null, "id": 3, "last_request_at": "2012-04-04T10:27:40Z", "login": "injoit", "owner_id": 4, "phone": null, "twitter_id": null, "updated_at": "2012-04-04T10:27:40Z", "website": null, "user_tags":"superman" }
その後、アプリケーショントークンは既にユーザーのトークンになります。
セッションは、 http://api.quickblox.com/auth_exitでの直接DELETE要求によって破棄されるか、1時間非アクティブになった後、システム自体がトークンを削除します。
curl -X DELETE "https://api.quickblox.com/auth_exit?token=422ce2791d7070b88a82f415b3693c81612e3423"
このセクションの主なドキュメントは、開発者: 認証と承認ページにあります。
発言。 最近、リクエストパラメータGET、PUT、POST、およびDELETEのトークンは非推奨になりました。トークンを指定する主な場所はリクエストヘッダーです。
curl -X POST -H "QB-Token: cf5709d6013fdb7a6787fbeb8340afed8aec4c69"
これは重要なセキュリティ更新プログラムであるため、すべての既存のSDKおよびサンプルはそれに応じて更新されます。
明確化、相互協力、またはQuickBloxの使用に関する質問については、私にkorjikとTaras qbtarzanに連絡するか、 andrey.kozhokaru @ quickblox.comにメールしてください 。