6

同じドメイン上の 2 つの異なるステートフル ページを指す 2 つの iframe をデプロイすると、JSESSIONID が上書きされる可能性があるという私の理論を確認または反論する人を探しています。これが私が意味することです：

設定

  1. 正しく機能するために HttpSession 状態 (セッション アフィニティ) を必要とする 2 つのページがあり、 http: //www.foo.com/ page1 とhttp://www.foo.com/ page2 にデプロイされているとします。
  2. www.foo.com が、セッション ID に JSESSIONID を使用する Tomcat (6.0.20、fwiw) を実行している単一のホストであるとします。
  3. これらのページが 2 つの iframe ウィジェットに変換され、サード パーティのサイトに埋め込まれているとします: http://www.site.com/page1" /> (およびそれぞれ /page2)
  4. http://wwwの同じページに両方のウィジェットを配置したいサードパーティのサイトがあるとします。bar.com/foowidgets.html _

次の競合状態が発生する可能性はありますか?

  1. 新しい訪問者はhttp://www.bar.com/foowidgets.htmlにアクセスします
  2. ブラウザーは、2 つの iframe 'src' URL を含む foowidgets.html の URL の読み込みを開始します。
  3. ブラウザーは同じホストに対して複数の同時接続を開くため (chrome/ff の場合は最大 6 つ)、ブラウザーはたまたまhttp://www.foo.com/page1と http://www.foo.comの要求を同時に発行します。 /ページ2
  4. tomcat @ foo.com はほぼ同時に両方のリクエストを受け取り、(2 つの異なるスレッドで) getSession() を初めて呼び出し、2 つの HttpSession を遅延して作成します。また、リクエストはそれぞれのセッションにデータを詰め込みます (そのデータは後続のリクエストを処理するために必要になります)
  5. ブラウザが最初に page1 リクエストへのレスポンスを受信すると仮定します。ブラウザーは、HOST www.foo.com の Cookie JSESSIONID=$Page1 を設定します。
  6. page2 要求に対する次の応答が受信され、ブラウザー は HOST www.foo.com のCookie JSESSIONID を $Page2 で上書きします。
  7. ユーザーが foowidgets.html の「page1」iframe 内の何かをクリックします。ブラウザは http://www.foo.com/page1?action=doSomethingStatefulに 2 番目のリクエストを発行します。そのリクエストは JSESSIONID=$Page2 を運びます ($Page1 ではなく - Cookie の値が上書きされたため)
  8. foo.com がこのリクエストを受け取ると、間違った HttpSession インスタンスを検索します(JSESSIONID キーが $Page2 であり、$Page1 ではないため)。フーバー！

上記は起こりえますか？と思いますが、ご確認いただければ幸いです。

上記が明らかに可能である場合、ページごとに複数の iframe をサポートしたい場合、どのような解決策がありますか? iframe が同じ HttpSession を共有する必要はありませんが、それは良いことです。解決策が iframe ごとに別個の HttpSession を規定する場合、もちろん、iframe 1 が自分の代わりに iframe 2 の httpSession 状態を参照しないようにすることが必須です。

頭のてっぺんから次のことを考えることができます：

  1. page1 と page2 を異なるドメインにマップする (ops オーバーヘッド)
  2. URL 書き換えを使用し、Cookie を使用しない (分析を台無しにする)
  3. 他に何か？

どうもありがとう、ニキータ

4

3 に答える 3

1

TL;DRシナリオは正しく、一方のセッションが他方のセッションをオーバーライドし、両方のページがセッションを共有します。しかし、それは問題ではありません。

上記の例では、ほぼ同時に 2 つのステートレスな匿名リクエストがあります。

言い換えれば、リクエストに固有のものはまったくありません。2 つの一般的なページが返されます。これらのページは両方とも、競合のためではなく、リクエスト自体が匿名であるため、新しい JSESSIONID を持つことになり、基本的に Tomcat に新しいセッションの作成を依頼します。

page2 が JSESSIONID スピード コンテストで優勝し、ブラウザに page2 Cookie があるとします。次に、ユーザーが page1 のアクションをクリックします。リクエストが page2 Cookie でラベル付けされることは正しいと思います。

しかし、だから何？

Page1 にはセッション関連の情報を含めることができないため、ユーザー固有の情報を含めることはできません。したがって、それからのアクションには、セッション関連の状態はありません (状態は作成されたばかりです)。特定のセッション関連の状態がない場合、「間違った」JSESSIONID で問題が発生することはありません。

別の見方をすると、page2 のリクエストが page1 のリクエストの前に完全に処理されていた場合、page1 はどのように異なるでしょうか? 違いはわかりません。2 つのシナリオで返された HTML に違いがない場合、JSESSIONID が交換されても問題ありません。

OTOH、ユーザーが既に bar.com にアクセスしたことがある場合、page1 と page2 の両方のリクエストは同じ JSESSIONID に関連付けられ、返されるページは正しく、foo.com の世界ではすべて問題ありません。

1 つの問題: CSRF保護がオンになっている場合。CSRF ライブラリは、返されたページのすべての URL を変更して、追加のパラメーターを含めます。CSRF 保護ライブラリは、セキュリティ トークンが JSESSIONID と一致するすべての着信要求をチェックします。page1 が page2 の Cookie を使用する場合、CSRF 保護はリクエストを偽造として拒否します。

iframe ごとに 1 つのセッションが必要な場合: URL 書き換えを使用します。これはもともと、ブラウザが Cookie を受け入れない場合にセッションを管理するために設計されました。うまく機能しますが、URL は見栄えが悪いです。

于 2013-04-24T06:19:23.030 に答える
0

page1とpage2が異なるコンテキストを使用する場合、それらは両方とも、お互いのスコープに干渉することなく、サードパーティのiframeを介して機能します。

JSPでセッションを制御するにはさまざまな方法があります。この質問の一番の答えは、適切な解決策を見つけるのに役立つかもしれません 。JSESSIONIDはどのような条件下で作成されますか？

于 2011-09-14T09:17:49.060 に答える
0

あなたが言っていることは正しいです、それはメソッド HttpServletResponse.encodeURL() の存在理由です。

2 つの iframe を含むページが page1 および page2 と同じコンテキストにある場合、iframe 内の URL はこのメソッドでエンコードするか、JSTL の <c:url> タグで取得する必要があります。

Cookie がまだ定義されていない場合は、URL に JSESSIONID が追加されます。

于 2010-03-22T12:44:38.917 に答える