永続的なログインCookieを並列AJAXリクエストと組み合わせる方法は？

Question

「私を覚えている」オプションのためにImproved Persistent Login Cookie Best Practiceを実装しました。

これは、要求が順番に行われている場合（従来のページ読み込み時）に問題ありません。この場合、次の要求には、サーバーが最後に送信した一連の識別子とトークンが同じであることが確認されます。

しかし、同じブラウザから複数のリクエストが並行して到着するAJAXリクエストの場合、最初のリクエストでは新しいトークン番号が生成されます。しかし、他のリクエストには、この新たに生成されたトークン番号は含まれず、盗難と見なしてアクセスを拒否します。

この問題を回避するにはどうすればよいですか？

Answer 1

私はCSRF（クロスサイトリクエスト偽造）保護トークンを思い出しました。 CSRFトークンは、認証されていない「機能実行」の可能性を無効にすることによってアプリケーションを保護します。そして、彼らは、各応答に非理性的なトークンを発行し、要求を受け取ったときにそれを確認することによってそれを行います。

この機能は、元のセッションが長くなくなってもユーザーがログインできる機能です。彼のユーザー名/パスワードを再度提供する必要はありません。成功したログインごとに1回または1回、Remember meトークンを設定する必要があります。すべての応答ではありません。すべてのレスポンスにセッションクッキーを設定しないでくださいなぜ私はトークンを設定しますか？

Answer 2

私は同じ問題があるので、これについて少しお読みになりました。

Barry JaspanとCharles Millerのテクニックは、サーバー上に新しいトークンを生成してクッキーに適用する間に、多くのことが起こることがあるため、（特にAJAXの設定では）使用できないようです。

この場合、非同期性がありますが、値がサーバーに保存されているクッキーで終わることはありません（たとえば、ロード前にページから移動するなど）。

バリーはacknowledge thisと思われます。

第2に、トークンを無効にすると（パスワード変更など）、「ゴースト」クッキーが多くなります。そのうちの1つを使用する各アクセスは、他のすべてのセッション（その中で有効なものを持つ可能性が高い）を無効にします。これらの制限の

、私は最善の解決策は、の組み合わせだと思う：

• HTTPS（SSL）すべての要求
• 追跡に
• この技術が、なしの再生成を使用しますユーザーによる無効化（上記の2番目の注釈を処理する）
• HTTP専用クッキー（スクリプトへのアクセスを避けるため）

私はBarryにメッセージを送って、彼のページでこれに関する通知を検討しました。

Answer 3

前述のDrupalスレッド（https://www.drupal.org/node/327263#comment-3428038）の提案された解決策に基づいて、より単純なアルゴリズムを使用できないのかどうか疑問に思っています。

「古い」置き換えられたトークンを短命のキャッシュテーブルに格納する代わりに、現在のユーザーセッションを使用しないのはなぜですか？

1. User logs in with PL cookie 
If series & token are in PL table: 
    2. User session is populated with the last valid token 
    3. new token is given to client 
    4. user is logged in 
If series key is in PL table, but token is not: 
    2. check if current user session still holds the latest replaced token 
    If found: 
    3. user is logged in. No new token is provided since one was generated in the first request. 
    If not found: 
    3. Assume keys are stolen - series is destroyed 

セッション状態を適切にかかわらず、すべてのノードにレプリケートされない場合は、このアルゴリズムは、しかし、負荷分散シナリオでは動作しません！