![当在另一个域的 IFrame 中使用 Cookie 时,IE 不会发送 Cookie](https://linux22.com/image/563382/%E5%BD%93%E5%9C%A8%E5%8F%A6%E4%B8%80%E4%B8%AA%E5%9F%9F%E7%9A%84%20IFrame%20%E4%B8%AD%E4%BD%BF%E7%94%A8%20Cookie%20%E6%97%B6%EF%BC%8CIE%20%E4%B8%8D%E4%BC%9A%E5%8F%91%E9%80%81%20Cookie.png)
IE 8 和 9 在下次请求时不会发送 cookie。它在 Chrome 14 和 FF 6 中有效。
在我的例子中,我运行了一个使用 cookie 进行身份验证的 ASP.NET 3.5 Web 应用程序。如果不存在 cookie,则用户将被重定向到登录页面。
基础架构如下。父应用程序将我的 ASP.NET 页面嵌入 iframe 中。ASP.NET 应用程序不是直接定位的,而是通过负载平衡器定位的。在父页面和负载平衡器之间使用 HTTPS 连接。负载平衡器本身通过另一个 IIS 代理连接到实际的 ASP.NET 应用程序,但此连接是通过标准 HTTP 建立的。父应用程序和 ASP.NET 应用程序不在同一个域中运行。
该 cookie 被标记为“仅 HTTP”。Jeff Atwood 有一篇很好的博客文章关于“仅 HTTP”-cookie,但仍然没有说明 cookie 是否也通过 HTTPs 发送。
登录 ASP.NET 页面后,响应包含 cookie 和重定向。当浏览器执行重定向时,cookie 不包含在请求中。这就是为什么 ASP.NET 应用程序假设一个新用户并再次重定向到登录页面的原因。
所以我的问题是,为什么 IE 不发送 cookie。是因为 cookie 被标记为“仅 HTTP”吗?如果是这样,有人能告诉我如何禁用此 ASP.NET 功能吗?在论坛上说,您无法关闭此功能。但是我发现了一种禁用它的笨拙方法,如果可能的话,我想避免这种情况。
顺便说一句,如果我将 ASP.NET URL 添加到受信任的站点,它就可以正常工作。无论如何我都需要避免这些。
更新 1: 有趣的是,如果我通过 HTTPS 直接进入位于 ASP.NET 页面前面的负载均衡器,cookie 将被正确发送到负载均衡器。只有当站点位于父页面的 iframe 中(带有无效证书)时,cookie 才不会被发送。
更新2: 为了说明这种情况,我添加了 2 张描述架构的图片。第一张解释了环境,第二张显示了 IFrame 发出的 2 个请求的过程。对第一个请求的响应包含 2 个 cookie。对完全相同的应用程序的以下请求不包含 cookie。如果我 a) 将负载平衡器(以及最后的 ASP.NET 应用程序)添加到受信任的站点,或者 b) 直接在浏览器中转到负载平衡器(以及最后的 ASP.NET 应用程序),而不是通过托管 IFrame 的父页面,则 cookie 会被发送。抱歉,我很想添加图片,但我没有 10 个代表,所以 Serverfault 不允许我...
更新 3: 父页面和 ASP.NET 页面托管在不同的域上。示例: - 父页面 yourapp.com - 托管在 iframe 中的 ASP.NET 页面:myapp.com
答案1
答案2
这是因为该 cookie 被标记为仅 HTTP。IE 假定仅 HTTP cookie 应仅发送回其来源。它不认为 HTTPS 和 HTTP 源是等效的。可以说,这更合乎逻辑——如果我通过安全连接收到仅 HTTP cookie,为什么我要通过不安全的连接发送它?
有一个解决方法——不要在 HTTPS 页面上仅设置 HTTP cookie。相反,在重定向的 HTTP 页面上,再次设置 cookie,但这次仅将其设置为 HTTP。这应该可以解决问题。
(为了好玩,再检查一下 URL 是否链接到精确的相同的主机名。例如,不要重定向www.mydomain.com
到。)mydomain.com