こんにちはKhabrovtsy!

今日は、
QuickBloxの認証方法について
説明します。 承認とその側面に影響を与えます。
そのため、
QuickBlox APIへのリクエストには
tokenを添付する必要があり
ます 。 認可リクエスト自体以外。
QuickBloxには4つの許可エンティ
ティーがあります。
アプリケーションは、読み取り専用特権を持つエンティティです。 たとえば、
アプリケーショントークンを使用すると、評価や場所へのリクエストなど、多くの情報リクエストを実行できます。
アプリケーショントークンで使用できる書き込み操作は、ユーザーの作成のみです。 このエンティティは、次のデータセットで認証されます。
このデータセットは、すべてのエンティティの認証の標準であり、アプリケーション設定で確認できます。
ユーザーとは、プッシュメッセージを受信するための登録など、おそらくデバイスに関連する操作を除き、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にメールして
ください 。