views:

5894

answers:

12

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: http://stackoverflow.com/questions/179260/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.

+4  A: 

There are multiple possibilities behind this -

  • UAC & Vista (Had to crop up!!). Specifically, look for protected mode behavior.
  • This could be an actual problem with the Session Merging feature in IE8. More so because opening a new window via the Ctrl+N shortcut causes the cookies to be magically sent in your case.
  • An issue with an older build of IE (I know you have stated that your customers are using the latest build). You might want to check the details available at Microsoft Connect for bug IDs 408806 and 392032.
Vineet Reynolds
It's not protected mode. It is related to the Loosely-Coupled IE feature, which is related to Session Merging. We had a bunch of bugs here during the IE8 Beta and RC. We fixed those. I believe all open bugs in this space have been fixed in RTM + Full patches, so be sure that the user has all of the latest patches installed.If you can send me a .SAZ file (Fiddler export) I'll have a look.
EricLaw -MSFT-
The affected users all definitely appear to have the latest patches, and are a mix of both Vista and XP. However, I can't help shake the feeling that there might be a regression here.However, the fact that I can't reliably reproduce this is making it difficult to prove or disprove this.When I can get this level of access to a problematic machine, I'm going to try following the Hyperthreading recourse seen in the Beta and RC bugs.I'll be sure to send along a Fiddler export as well. Thanks.
HackedByChinese
+1  A: 

I would be curious to hear if there is a resolution and/or workaround for this as we are experiencing the same issue.

Hi Tom. I don't have a permanent resolution, but as stated under Update in the issue, it seems adding users as Local Administrators on their computers has had a positive effect.
HackedByChinese
A: 

I know this problem since IE 5, so I only use session's variables in modal pop-up windows... When I open a non-modal pop-up window, I replace all session's variables with ASP.NET cache and new object collections... But it's very tiresome!

Other browsers (i.e. Firefox) don't have this problem...

Bye Alberto

+1  A: 

This is 'new' functionality in IE8!

Checkj out the IE8 blog below to read about it.

http://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx

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

Enterprises can modify the setting via GP, but that's really missing the point: IE will ensure that the new process has the old processes cookies. If it didn't, that would be a bug, and such bugs were squashed before the final version was released.
EricLaw -MSFT-
A: 

We're experiencing the same issue. We have a login apge that a portal opens using window.open. This is part of an SSO process, so the login page checks a token in the querystring then if all is OK, writes some information into the session and uses a Server Side redirect to render our normal Default.aspx page into the new window.

Watching Fiddler we see the session cookie being written to the browser as the page is returned. That cookie is passed back with every request required to complete rendering of the page (i.e. as each JPG is downloaded). So the cookie has made it back to the browser.

Then the user presses a button on the page (in the new window) which fires off a POST directly to Default.aspx page (same virtual directory and both over HTTP). This request doesn't contain the session cookie. At which point our application sees a blank session, so our functionality sends them to a "logged out" page.

If the user, closes the new browser window, a launches a second one, everything works fine.

We get this problem with IE7 and IE8. Fire Fox does not have the problem.

Piers
A: 

We had this problem on IE6,7 and 8 .The scenario is parent window(1) opens a modal window(2),modal window has a link to a non-modal window (3). I used to get a different session Id in the 3rd window.

Workaround mentioned here fixed the issue http://support.microsoft.com/kb/831678

Vishwa Kumar
A: 

Since IE8 we (and our customers) are also experiencing the same issue. We have an asp service for creating forms. This application uses new windows for adding elements or managing user accounts e.g. Randomly (when opening a new window), the application doesn't get the required session id for authentication allong with other 'permanent' cookies. Hence, the session id is a temporary cookie. Most of the time it goes well, but other times the session is broken every time a new window is opened. We have to advise our customers to close all IE windows and start over again.

As a web developer I use IE extensively. Personally, I am not experiencing the above issue. But I think a related one. A few times a day IE totally hangs (does not respond anymore) when opening a new window. When I kill a certain IE process using the task manager, IE starts responding again. But in most cases it's better to start all over with a clean new instance of IE. For this reason I just kill the process with the least ram usage which causes all IE processes to quit.

Microsoft saying these issues/bugs are squashed in the final version does not give me trust of their effort solving the issue still be experienced.

W. Hörchner
A: 

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.

Adding the user to Local Administrator does resolve the issue. But this is not a viable solution in our case. Do you know why local admin works? Is there a security setting that is causing the local admin to behave correctly?

Ron
A: 

Has anyone found a real solution for this? Our testing has determined this to be specific to IE8 on a 64 bit machine. IE8 on a 32 bit machine works correctly for this scenario. Tried the 32 bit and 64 bit version of IE8 on the 64 bit machine, and they both had the same issue.

The testing was done using Windows Server 2008 Standard Edition.

Thanks, DK

D Kantala
A: 

Same problem here! Is there a fix? We can't add the user to the local admin account. We are talking about a 500 user corporate network. The problem appeared when we upgraded our users to Window 7 (64 bit) with IE8.

Shayne
A: 

We solved this problem by changing the "Set tab process growth" to 0.

Although, we didn't have protected mode turned on and the zone was "Intranet". Evidently this is a problem/bug with Windows 7 64Bit as others have stated.

This page (#4) lead me to the solution: http://blog.httpwatch.com/2009/04/07/seven-things-you-should-known-about-ie-8/

Shayne
A: 

I have a similar, though not identical problem. We load a webpage that opens a popup with window.open() into an IE browser control. On machines that have either IE6 and IE8, the popup window is always assigned a new SessionID by ASP when launched from the control. However, when launched from a normal browser (IE or Firefox), the popup window gets the existing SessionID.

I can see when launching from the control that a new iexplore.exe process is spawned; thus the session loss behavior makes sense given what has been mentioned about in-memory cookies not being carried over to the new process.

I'm still trying to figure out a workaround myself ...

Update

Figured out a workable fix! It is possible to subclass SessionIDManager and specify that this class should be used instead of the default (<sessionState sessionIDManagerType="..."> in Web.config). The subclass can look for a query parameter containing the existing session id in an override of CreateSessionID(), and return it if found. This essentially allows a page to request being "merged" into an existing session it has knowledge of.

The call to window.open() then simply needs that query parameter specified in its URL.

Haw-Bin

Haw-Bin