7

環境:

JSON データを Rails-API サーバー (Rails 4) と交換する Ember.js 1.1.0-beta.1 アプリケーションがあります。JSON データ交換は、Ember-Data 1.0.0-beta.2 と Active Model Serializers 0.8.1 (AMS) で実現されます。私は Ember-Data と AMS の両方でデフォルトの推奨構成を使用しており、JSON-API 仕様に準拠しています。

特定の RESTful 呼び出しで、クライアントは現在の認証トークンをサーバーに渡します。認証トークンが検証されて廃止され、新しい認証トークンが生成されてクライアントに送り返されます。したがって、すべての RESTful 呼び出しは要求で認証トークンを受け入れ、クライアントがキャッシュして次の RESTful 呼び出しに使用できる新しい認証トークンを応答で提供します。

質問:

各リクエストとレスポンスのどこに認証トークンを配置すればよいですか?

リクエストとレスポンスで各オブジェクトの JSON の一部にする必要がありますか? その場合、トークンは既存のオブジェクトの JSON 構造 (認証とは関係ありません) のどこに配置されていますか?

それとも、各リクエストおよびレスポンス オブジェクトの HTTP ヘッダーに配置する必要がありますか?

新しい Ember Guides Cookbook で最終的に期待される「The Ember Way」とは何ですか?

詳細なコンテキスト:

私はすでに次のリンクに精通しています。

...そして、これらを超えた、Ember-Data + AMS に固有の回答を探しています。

Ember-Data を介して応答で新しいトークンをクライアントに返す必要があることを除いて、私のクライアント コードが GitHub の @machty Embercast の例に似ていると仮定します: https://github.com/embercasts/authentication -part-2/blob/master/public/js/app.js

どうもありがとうございました!

4

2 に答える 2

3

同様のスタックがあります-ember、ember-data、およびrails-api with AMS。現時点では、認証トークン (localStorage に保存) をヘッダーに渡しているだけです (ただし、クエリ文字列で渡すこともできます)RESTAdapterajaxメソッドを変更します。

私の最初の考えは、リクエストごとにトークンをリセットしないようにすることです。トークンがスニッフィングされることを特に懸念している場合は、定期的な間隔 (たとえば 10 分) でサーバー上のトークンをリセットする方が簡単な場合があります。次に、古いトークンが原因でクライアントからのリクエストが失敗した場合は、(サーバーがログイン時に提供する「リセット トークン」を渡すことによって) 新しいトークンをフェッチし、最初のリクエストを再生します。

トークンを配置する場所については、実際には「Ember Way」はありません。クエリ文字列でトークンを渡すと、キャッシュが混乱する可能性があり、途中でログに記録される可能性が高くなるため、ヘッダーで渡すことを好みます。リクエスト本文でそれを渡すことは絶対に避けたいと思います-それは ember-data が期待するものに反するでしょう。

于 2013-09-25T17:40:32.847 に答える
2

ユーザーがサインアウトしない限り、トークンをリセットしませんが、同様のものを作成しました。

リクエスト本文自体には入れません。モデルを汚染するだけです。これは輸送の問題であるため、おそらく Ember の方法はありません。カスタム HTTP ヘッダーや Cookie を使用してトークンを渡します。Cookie はファイルのダウンロードを承認するために必要であり、これは ajax では実行できませんが、Cookie は ajax 呼び出しでも機能します。あなたの場合、私はクッキーを使用し、サーバーに毎回新しい値を設定させます。ただし、各 JSON リクエストでトークンをリセットするスキームは、同時リクエストでは機能しません。これは本当に必要ですか?TLS を使用している場合は、おそらくそれほど心配する必要はありません。トークンをタイムアウトして、10 分間リクエストがない場合に新しいトークンが生成されるようにすることもできます。

于 2013-09-23T20:38:07.307 に答える