10

Webサイトに「rememberme」機能を実装しているときに、セッショントークンとは別に、物事を複雑にし、remembermeトークンと呼ばれるトークンを使用するのはなぜですか。

私の理解の限りでは、セッショントークンは数分間、またはユーザーがブラウザを閉じるまでしか持続しないのに対し、トークンを使用してログインして新しいセッショントークンを作成できることを覚えておいてください。セッショントークン自体の有効期限を、ユーザーがログインするまでの希望の時間まで延長できないのはなぜですか?

このような機能をTomcat上で実行されるフレックスベースのアプリケーションに実装する必要があり、トークンを覚えておく必要があるのではないかと思います。

また、Tomcat内でこの機能をすぐに使用できるようにすることは可能ですか?

4

5 に答える 5

16

1)セッションには通常、ユーザーのログイン名以外の大量のデータが含まれます。したがって、remember meトークンのように有効期限を数週間または数か月に設定した場合、数千または数百万のヘビーウェイトセッションオブジェクトが原因でサーバーのパフォーマンスの問題が発生する可能性があります。

2)トークンはサーバー側ではなく、クライアント側であることを忘れないでください。これにより、すべてのストレージ要件がユーザーのブラウザに適用されます。これは、ログイン名などの単純なデータに適したソリューションです。サーバー上のメモリ内オブジェクトにリンクされたセッションIDに依存している場合、サーバーまたはサーバープロセスを再起動するたびに(たとえば、更新されたアプリケーションを展開するために)、それらのセッションオブジェクトはすべて失われます。

于 2011-03-18T13:05:44.520 に答える
4

定義上、セッションはユーザーがブラウザを閉じるとすぐに終了するためです。したがって、セッションCookieは、ブラウザが閉じられるとすぐに期限切れになります。

Remember-me機能の目的は、ユーザーがセッション間でログインし続けることであるため、remember-me Cookieに保存されている情報は、ブラウザーの再起動後も保持される必要があります。

この機能を「すぐに使用できる」ようにするには、SpringSecurityなどのフレームワークの使用を検討してください。

于 2011-03-15T16:32:10.237 に答える
1

覚えておいてください-私クッキーは通常、ユーザー名とある種のトークンを保存します。どちらもユーザーの認証に使用されます。プロセスを非常によく説明している、改善された永続ログインCookieのベストプラクティスをご覧ください。

セッションCookieは、クライアントにセッションIDを格納するために使用されます。これにより、サーバーはセッションを認識し、セッションに関連付けられているセッションデータをロードできます。

したがって、覚えておいてください-私のCookieは、セッションCookieよりも寿命が長くなります(通常は数日または数週間)。セッションCookieは通常、数分後またはブラウザを閉じたときに期限切れになります。

私の頭のてっぺんから、2つの異なるCookieが使用される理由がいくつかあります。

  • 永続的なremember-mecookieのみが使用される場合、サーバーはすべての要求でユーザーを認証する必要があります。追加のセッションCookieが使用される場合、セッションが有効である限り、サーバーはこれを行う必要はありません。もちろん、セッションIDはremember-me cookie内に保存できますが、それを行う意味は何ですか?
  • コーディングの観点からは、既存のセッションメカニズムを再利用することをお勧めします。簡単に有効/無効にできる機能(remember-me cookieによる認証)を追加するだけでなく、車輪の再発明を行うのはなぜですか?
于 2011-03-18T09:27:38.050 に答える
0

人々は、セッションには多くの重いオブジェクトが含まれていると正しく言っています。システムに十分な数のユーザーがいる場合、サーバーが持つ有限量のメモリにすべてのユーザーを保持しようとすると、最終的には、そのメモリの最大数がなくなるとサーバーがクラッシュします。

プロダクションコードの更新でメモリリークが発生したプロジェクトに一度取り組んだことがあります。これはJ2EEプロジェクトでした(はい、Java EEではなくJ2EEです)。ユーザーがこの電話会社で請求書を確認するためにログインしたとき、ユーザーセッションがメモリから適切に解放されませんでした(原因を思い出せませんが、それは間違いなく問題でした)。このバグは、意図的に実行することについてあなたが求めていることを模倣しています。

サーバーがクラッシュし続けました。そこで、プロファイラーを配置します。アプリサーバーがクラッシュした直後にメモリ使用量がいっぱいになり、すぐに使用されるまで、メモリ使用量が1日を通して増加するのを監視していました。メモリを追加し、VMメモリ設定を増やしました。私はメモリリークだと言いましたが、私は1時間あたり$ 200.00の「サーバーエキスパート」ではなかったため、ガベージコレクターは非常に優れているのではなく、すべて強力であると信じていたため、人々はそれを信じたがりませんでした。

2日後(メインのビジネスシステムではなく、「請求書の表示」システムに影響しました。つまり、サーバーに十分なハードウェアメモリがあるにもかかわらず、同じワークロードまたはメモリ要件がありませんでした)、彼らは2、3人を雇いました。 1日後にアプリに前述のメモリリークが発生したと言ったコンサルタントは、1時間あたり$200.00です。それは修正され、すべてが良かった...コンサルタント費用を差し引いた。

いずれにせよ、これはこれからの脱却です。ユーザーがログアウトしたりブラウザを閉じたりするときにユーザーセッションを終了しないと(セッションタイムアウト)、メモリが最大になりサーバーがクラッシュするという本当のリスクがあります。特に、サイトまたはアプリにかなりの数のユーザーがいる場合。他の人が述べているように、軽量のトークン/クッキーが最適です。

于 2012-06-17T15:46:14.170 に答える
0

ユーザーを記憶するためにsessionIdcookie以外の別のcookieを使用する必要がある理由は、セッションがすぐに期限切れになるか、サーバーでパフォーマンスの問題が発生するためではありません。

Jetty(およびおそらく他の多くのサーブレットコンテナ)には、メモリからディスクまたはデータベースへのアイドルセッションの自動削除を可能にする機能があり、IMHOは、重いセッションをメモリに格納することに伴うパフォーマンスの問題に関する上記のすべての正当化を除外します。

別のCookieが使用される理由は、remember-meは、セッションの有効期限が切れた後でもユーザーを記憶するためです。したがって、ユーザーのセッションが期限切れになった場合、他のCookieを使用して、パスワードを入力せずにユーザーを認証します。これにより、フィッシング攻撃の可能性が明らかに低くなります。それにも欠点がありますが、たとえば、誰かがあなたのラップトップにアクセスして認証トークンを盗んだ場合、サーバーがトークンをクライアントと場所のみにバインドするためにさらに多くのセキュリティ対策を適用しない限り、あなたになりすますことができます。

つまり、remember-meは認証メカニズムであり、セッションCookieの代わりにはなりません。

長期のセッション有効期限は、メモリから保存されている限り問題ないと思います。有効期限が切れたら、パスワードを要求するだけです。多くのWebサイトでは、この機能を「30日間記憶してください」として提供しています。これは、長期のsessionIdCookieを使用するだけで実現できます。

于 2016-12-06T16:43:16.780 に答える