5

「rememberme」オプションの改善された永続ログインCookieのベストプラクティスを実装しました。

これは、リクエストが順番に並んでいる場合（従来のページの読み込み）に正常に機能します。この場合、次のリクエストには、サーバーによって最後に送信されたものと同じシリーズ識別子とトークンが含まれていることを確認してください。

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

この問題をどのように回避しますか？

4

3 に答える 3

1

前述の 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

ただし、セッション状態がすべてのノードに適切にレプリケートされていない場合、このアルゴリズムは負荷分散シナリオでは機能しません!

于 2017-04-23T21:01:05.433 に答える
0

私は同じ問題を抱えているので、これについて少し読んでいます。

BarryJaspanとCharlesMillerの手法は、サーバーで新しいトークンを生成してからCookieに適用するまでの間に、多くのことが発生する可能性があるため、（特にAJAXセットアップでは）使用できないようです。

私たちの場合、これは非同期の性質ですが、値がサーバーに保存されているときにCookieに含まれない場合もあります（たとえば、ロードする前にページから移動するなど）。

バリーはこれを認めているようです。

次に、トークンを無効にすると（パスワードの変更など）、多くの「ゴースト」Cookieが発生します。それらの1つを使用するたびに、他のすべてのセッションが無効になります（その時点で、有効なセッションが含まれている可能性があります）。

これらの制限があるため、最善の解決策は次の組み合わせだと思います。

  • HTTPS（SSL）の使用
  • この手法ですが、リクエストごとに再生成する必要はありません
  • ユーザーによる無効化の追跡（上記の2番目のコメントを処理するため）
  • HTTPのみのCookie（スクリプトによるCookieへのアクセスを回避するため）

私は彼のページでこれについての通知を検討するためにバリーにメッセージを送りました。

于 2013-02-12T10:43:18.870 に答える