1

我有一个在本地环境中托管的应用程序，并且遇到了一个仅在 IE 中出现的非常奇怪的问题。我测试过的其他浏览器（Chrome 和 Firefox）似乎没有重现该问题。

我正在使用 Wicket 1.5.0 快照。

在应用程序中，我有一个调度页面，它验证初始请求并在验证后采取进一步的行动。在里面我有：

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

并且在调用 MyCustomSession.get() 的 Canvas 页面中，它为每个请求返回一个全新的会话，这会导致问题，因为我之前放入会话中的所有数据都消失了。

然后我追查了问题，在我看来，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 应用程序，因此包含在 iframe 中（因为被 FB 嵌入）并且 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 回答