2012-04-13 11 views
1

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

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

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

MyCustomSession.getを(呼び出し時に
setResponsePage(Canvas.class, pageParams); 
MyCustomSession.get().bind(); 

とキャンバスページ内の)すべてのデータは、私が以前に入れてきたので、それが問題を引き起こし一人ひとりの要求のためのブランドの新しいセッションを返します。セッションは終了しました。

私はこの問題を追跡しました。私には、IEがいつも要求ヘッダーに同じようなjsessionidを送信するように見えます。 - 8302844E8BB8FD6D1A617C0E6A2C58C3。 setResponsePage(Canvas.class、pageParams)の応答ヘッダに

、次のように302のステータスコードとIは、応答ヘッダを見た:

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

関係なくのIEからのすべての次の要求は、そのヘッダフィールドを有しています(前と同じセッションID):

Cookie JSESSIONID=8302844E8BB8FD6D1A617C0E6A2C58C3 

本当に私を悩ますので、これを解決するためにお手伝いをしてください。ありがとう!

+0

Wicketでテストしてください。1.5.5 – jordeu

+0

@jordeu 1.5.5で修正されている特定のバグがありますか、それともちょうど推測していますか? –

+0

推測...しかし、最初の1.5.xバージョンにいくつかのセッション関連のバグがあったことを覚えています。 – jordeu

答えて

2

は、実際に問題がクッキーが全く送信されなかったということでした。さらに検討したところ、第三者のコンテンツ通信(IEの用語ではそれを定義する)の問題であることが判明しました。

私たちのアプリケーションはFBアプリケーションであるため、iframe内に含まれています(FBによって埋め込まれているため)。IEのセキュリティ設定は、この場合はサードパーティのコンテンツにCookieを送信することを拒否していました。いくつかの調査の後、P3P(Platform for Privacy Preferences Project)ヘッダーを私たちの回答に入れると、これらのポリシーを満たし、IEがリクエストヘッダーにCookieを送信できるようになることが分かりました。

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

0

基本的に野生の推測:ブラウザに同じドメインの/というパスに保存されたJSESSIONIDクッキーがこの奇妙な動作を引き起こしますか?おそらく、IEは/apppathのために格納されたものの代わりにこのクッキーを送信するでしょう。

どこかに私の頭の後ろで、私は同様の問題を覚えているようだが、残念ながら私は本当に解決策を思い出すことができない...

+0

多分あなたはhttps://vaadin.com/forum/#!/thread/1216367/1216366とhttp:// stackoverflowについて話しているでしょう.com/a/22493443/582789 –

関連する問題