IE8 在弹出窗口中丢失会话 cookie [英] IE8 losing session cookies in popup windows
问题描述
我们有一个使用 Forms Auth 的 ASP.NET 应用程序.当用户登录时，会生成会话 ID cookie 和 Forms Auth 票证(存储为 cookie).这些是会话 cookie，而不是永久 cookie.当浏览器关闭时，用户被有效地注销是有意且可取的.
一旦用户登录，就会使用window.open('location here');弹出一个新窗口.打开的页面实际上是用户在其余会话期间工作的工作区.在此页面中，还使用了其他弹出窗口.
最近，我们有许多客户(都使用最新版本的 IE8)抱怨他们登录时，初始弹出窗口将他们带回登录屏幕而不是主页.或者，用户有时可以登录，进入主页(同样是在一个新的弹出窗口中)，一切看起来都很好，直到创建任何其他弹出窗口，它开始将它们重定向到登录屏幕再次.
在尝试解决问题时，我使用了很好的老 Fiddler.当问题开始显现时，我注意到浏览器没有发送 ASP.NET 会话 ID 会话 cookie 或 Forms Auth 票证会话 cookie，即使对 POST 中的日志的响应清楚地推送了这些 cookie.
更奇怪的是，如果我 CTRL+N 从弹出的窗口中打开一个缺少会话 cookie 的新窗口，然后手动输入主页的 URL，那些 cookie 会神奇地再次出现.但是，后续的 window.open(); 调用将继续中断，不会发送会话 cookie 并将用户带到登录屏幕.
需要注意的是，有时，那些看似没有充分理由的用户可以突然登录并正常工作一段时间，然后又恢复崩溃.
现在，我确保没有浏览器加载项、插件、工具栏等在运行.我已将我们的站点添加为受信任站点并将安全设置降至低，我已将 Cookie 隐私策略修改为全部接受"，甚至禁用了自动策略设置，手动强制它接受所有内容并包含会话 cookie.似乎没有任何影响.
另请注意，Web 应用程序驻留在单个服务器上.没有负载平衡、网络花园、服务器群、集群等.服务器确实驻留在 ISA 服务器后面，但除此之外，它非常简单.
我已经搜索了几天，但没有找到任何可行的方法.哎呀，有时我什至无法可靠地重现它.我发现了一些对有同样问题的人的引用，但他们似乎引用了一个据称在 beta 或 RC 版本中修复的问题(例如:IE8 在重定向后打开新窗口时丢失 cookie).这些是 IE 的发布版本，带有最新的补丁.
我知道我可以尝试设置永久 cookie 而不是会话 cookie.但是，这对我们的应用程序具有严重的安全隐患.
更新
当用户被添加为机器的本地管理员时，问题似乎会自动消失.只有时间才能证明这一变化是否会永久(和积极地)影响这个问题.
是时候关闭 ProcMon 并查看是否存在资源访问问题.
更新 #2
对于看似单一的问题，似乎有多个角度.我很久以前就报告说，让用户成为本地管理员似乎有帮助.对于许多用户来说，它确实做到了.当然，这并不是真正的解决方案，但它确实让我们步履蹒跚.
然后越来越多的用户开始报告这个问题，而管理员修复也无济于事.用户似乎主要是 Win7，但 Vista 也受到了影响.它们似乎也主要是 64 位安装.
按照以下一些成员的建议将 TabProcGrowth 设置为 0 或 1(两者都有效)似乎在很大程度上解决了这个问题.所以，我将把我接受的答案移到第一个提出这个建议的人身上，因为它的影响要大得多.
这是一个难以解决的令人难以置信的令人沮丧的问题，因为它很难重现，而且经常发生在我没有直接联系的用户身上，或者当我找到他们时，它似乎不是在职的.我只能说会话合并功能有问题，但我没有太多数据可以提供给 Microsoft 以找到永久修复程序.
这是 IE8 中的新"功能！
查看下面的 IE8 博客以了解它.
IE8 可以使用多个进程来处理 x 个 IE 窗口.当您跨越进程空间时，您会丢失 cookie(Asp.Net 会话 ID 似乎保留在此进程边界上).
我个人认为它已损坏或存在错误.正如我们所知，当浏览到相同域目标"时，应该维护和重新发送 cookie.IE8 具有不同的安全处理行为.. 太好了！在我看来，它的行为很糟糕，并且即使转到另一个窗口中的相同目标域也会丢弃 cookie".
您可以通过 Internet Explorer 选项修改 IE8 使用的进程数 ehh.. 修改注册表设置！！！！！！(这就是我认为这是一个错误的原因.IE 提供一个 UI 来修改这些设置将使其企业级可接受".
问候，
马文·斯密特
We have an ASP.NET application that uses Forms Auth. When users log in, a session ID cookie and a Forms Auth ticket (stored as a cookie) are generated. These are session cookies, not permanent cookies. It is intentional and desirable that when the browser closes, the user is effectively logged out.
Once a user logs in, a new window is popped up using window.open('location here');. The page that is opened is effectively the workspace the user works in throughout the rest of their session. From this page, other pop-ups are also used.
Lately, we've had a number of customers (all using latest versions of IE8) complaining that the when they log in, the initial pop-up takes them back to the log in screen rather than their homepage. Alternately, users can sometimes log in, get to the homepage (which again, is in a new pop up window), and it all seems fine, until any additional pop-ups are created, where it starts redirecting them to the log in screen again.
In attempting to troubleshoot the issue, I've used good old Fiddler. When the problem starts manifesting, I've noticed that the browser is not sending up the ASP.NET session ID session cookie OR the Forms Auth ticket session cookie, even though the response to the log in POST clearly pushes down those cookies.
What's more strange is if I CTRL+N to open a new window from the popped-up window that is missing the session cookies, then manually type in the URL to the home page, those cookies magically appear again. However, subsequent window.open(); calls will continue to be broken, not sending the session cookies and taking the user to the log in screen.
It's important to note that sometimes, for seemingly no good reason, those same users can suddenly log in and work normally for a while, then it goes back to broken.
Now, I've ensured that there are no browser add-ons, plug-ins, toolbars, etc. are running. I've added our site as a trusted site and dropped the security settings to Low, I've modified the Cookie Privacy policy to "accept all" and even disabled automatic policy settings, manually forcing it to accept everything and include session cookies. Nothing appears to affect it.
Also note the web application resides on a single server. There is no load balancing, web gardens, server farms, clusters, etc. The server does reside behind an ISA server, but other than that it's pretty straight forward.
I've been searching around for days and haven't found anything actionable. Heck, sometimes I can't even reproduce it reliably. I have found a few references to people having this same problem, but they seem to be referencing an issue that was allegedly fixed in a beta or RC release (example: IE8 loses cookies when opening a new window after a redirect). These are release versions of IE, with up-to-date patches.
I'm aware that I can try to set permanent cookies instead of session cookies. However, this has drastic security implications for our application.
Update
It seems that the problem automagically goes away when the user is added as a Local Administrator on the machine. Only time will tell if this change permanently (and positively) affects this problem.
Time to bust out ProcMon and see if there is a resource access problem.
Update #2
It seems there are multiple angles to what appears to be a singular problem. I reported long ago that making the user a local administrator seemed to help. And it did, for a number of users. Of course, that's not really a solution, but it did let us hobble along.
Then more users started reporting the issue, and the admin fix was not helping. The users seemed to be mostly Win7, but Vista was also affected. They also seemed to mostly be 64-bit installations.
Setting the TabProcGrowth to 0 or 1 (either worked) as suggested by some members below seems to have largely addressed the issue. So, I'm going to move my accepted answer to the first person that suggested that, as it has had significantly more impact.
This has been an incredibly frustrating issue to attempt to solve, since it is difficult to reproduce and often occurs with users that I do not have direct communication with, or by the time I get to them it doesn't appear to be working. All I can say is something is not right with the session merging feature, but I don't have much data to feed to Microsoft to find a permanent fix.
This is 'new' functionality in IE8!
Checkj out the IE8 blog below to read about it.
IE8 can use multiple processes for handling an x number of IE windows. When you cross a process space, you loose your cookies (Asp.Net session ID seems to be retained over this process boundry).
I personally think it's broken or a bug. As we know, when browing to the 'same domain target' cookies should be maintained and resent. That IE8 has different processing behavior for security.. Great! that it is behaving badly and 'drops cookies even if going to the same target domain in another window' is just a bug in my view.
You can modify the number of processes IE8 uses through the internet explorer options ehh.. modifying a registry setting!!!!!! (this is what makes it a bug in my view. IE providing a UI to modify these settings would make it 'enterprise level acceptable'.
Regard,
Marvin Smit
这篇关于IE8 在弹出窗口中丢失会话 cookie的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
