ブラウザのタブ間で共有されているセッションを停止する必要がある Java Web アプリケーションがあります。つまり、
ユーザーはブラウザーを開き、自分のアカウントにログインして、同じブラウザーの新しいタブで特定のページを開きます。デフォルト設定では、セッションは新しいタブに共有され、ユーザーは新しいタブに自動的にログインします。アプリケーション全体ではないにしても、少なくともいくつかの機密ページでこれを制限できるように、これを停止する方法を誰にも教えてもらえますか。
ブラウザのタブ間で共有されているセッションを停止する必要がある Java Web アプリケーションがあります。つまり、
ユーザーはブラウザーを開き、自分のアカウントにログインして、同じブラウザーの新しいタブで特定のページを開きます。デフォルト設定では、セッションは新しいタブに共有され、ユーザーは新しいタブに自動的にログインします。アプリケーション全体ではないにしても、少なくともいくつかの機密ページでこれを制限できるように、これを停止する方法を誰にも教えてもらえますか。
通常、Cookie はセッション処理に使用されます。次に、すべてのタブとブラウザ ウィンドウが同じセッションを共有します。ただし、Cookie の代わりに URL 書き換えを使用するようにサーブレット コンテナーを構成できます。(これは Jetty の例です。)
URL 書き換えでは、セッションは、セッション ID を含む URL パラメーターを介してのみ識別されます。したがって、Web アプリケーションのすべての内部 URL は、メソッドを使用してこのパラメーターで拡張する必要がありますHttpServletResponse.encodeURL()
。Wicket のような Web フレームワークを使用している場合、これは既に行われている可能性が高いです。
URL 書き換えを使用すると、同じブラウザー インスタンスの異なるウィンドウまたはタブで複数の独立したセッションを持つことができます。
更新: 反対票に応えて、URL 書き換えのさまざまな動作を明確にしたいと思います。
Web サイトの URL がhttp://webapp.comであるとします。
Cookie:最初のブラウザー タブでhttp://webapp.comを 開きます。
サーバーはセッションを作成し、応答で Cookie を送信します。
ブラウザは Cookie を保存します。
次に、2 番目のブラウザ タブでhttp://webapp.comを開きます。ブラウザーは、この URL を最近保存された Cookie に関連付け、その Cookie を要求に追加します。
サーバーの場合、最初または 2 番目のブラウザー タブからの要求と同じセッションからの応答に違いはありません。場合によっては、これが望ましい動作です。
URL 書き換え:最初のブラウザー タブでhttp://webapp.comを 開きます。
サーバーは ID 1 でセッションを作成し、パラメーター jsessionid=1 を応答ページのすべての URL に追加します。Cookie は転送されません。
最初のブラウザー タブから同じ webapp の別のページへの以降のすべての要求には、セッション ID (例 1) が含まれます。
次に、2 番目のブラウザー タブからhttp://webapp.comを開きます。ここが違います!リクエストには Cookie も jsessionid パラメータも含まれていないため、サーバーは新しいセッション (つまり ID 2) を作成し、レスポンス ページに含まれるすべての URL にパラメータ jsessionid=2 を追加します。これ以降、2 番目のブラウザー タブからのすべての後続の要求は、セッション 2 に関連付けられます。
したがって、同じブラウザーに 2 つの独立したセッションがあります。
javascriptを使用している場合は、1つの回避策を提供できます。a)ログイン画面に1つの非表示パラメータを設定し、その非表示フィールドのウィンドウ名を設定しますb)ログイン(リクエストの送信)時に、アクションクラスでリクエストパラメータがnullでなく、ランディングページと等しいかどうかを確認します。有効なリクエストとは、無効なページにリダイレクトされない場合でも、ログインしてランディングページにアクセスすることを意味します。