1

ローカル環境でホストしているアプリケーションがあり、IE でのみ発生する非常に奇妙な問題が発生しています。私がテストした他のブラウザー (Chrome と Firefox) では、問題が再現されないようです。

私は Wicket 1.5.0 スナップショットを使用しています。

アプリケーションには、最初のリクエストを検証し、検証時にさらにアクションを実行するディスパッチ ページがあります。その中に私は持っています：

setResponsePage(Canvas.class, pageParams);
MyCustomSession.get().bind();

また、キャンバス ページで MyCustomSession.get() を呼び出すと、リクエストごとにまったく新しいセッションが返されます。これは、以前にセッションに入れたすべてのデータがなくなったため、問題を引き起こします。

次に、問題を追跡したところ、IEは常にリクエストヘッダーでまったく同じjsessionidを送信しているように見えます.8302844E8BB8FD6D1A617C0E6A2C58C3です。

setResponsePage(Canvas.class, pageParams) の応答ヘッダーで、ステータス コード 302 を使用すると、次のような応答ヘッダーが表示されます。

Set-Cookie JSESSIONID=91474844FC17D16B960A0760BA9DC129; Path=/apppath

それにもかかわらず、IE からのすべての次のリクエストにはそのヘッダー フィールドがあります (以前と同じセッション ID):

Cookie JSESSIONID=8302844E8BB8FD6D1A617C0E6A2C58C3

これは本当に気になるので、これを解決するのを手伝ってください。ありがとう！

4

2 に答える 2

2

実際の問題は、Cookie がまったく送信されなかったことです。さらに調べたところ、これはサードパーティのコンテンツ通信の問題であることが判明しました (IE の用語で定義されているように)。

私たちのアプリケーションは FB アプリケーションであるため、(FB によって埋め込まれているため) iframe 内に含まれており、IE のセキュリティ設定は、Cookie をサードパーティのコンテンツに送信することを拒否していました。調査の結果、応答に P3P (Platform for Privacy Preferences Project) ヘッダーを配置すると、これらのポリシーが満たされ、IE が要求ヘッダーで Cookie を送信できるようになることがわかりました。

この目的のために、Web プロジェクトにフィルターを作成して、アプリから送信される各応答にそのヘッダーを挿入しました。

于 2012-04-18T16:25:56.403 に答える
0

基本的に単なる推測です:/この奇妙な動作を引き起こすブラウザに同じドメインのパス用に保存された JSESSIONID Cookie はありますか? おそらく、IE は に保存されたものではなく、この Cookie を送信し/apppathます。

頭のどこかで似たような問題を覚えているようですが、残念ながら解決策は思い出せません...

于 2012-04-13T18:49:06.053 に答える