Problems with lost sessions

[Thomas Paul]

We seem to have encountered a problem related to a recent update of IE. It seems to apply to update Q813951.
The problem is that if we use redirection to a new page in a new window we lose the session. (The new page is in the same domain.) It seems like the session cookie gets lost and IE no longer sends the session cookie back to the server. Once this happens the session is completely lost and the user has to login again.
This is only happening to users who have installed the Q813951 update to their browsers. Since this is a new update we are seeing more and more users encountering this problem.
Q813951 is a security patch and can not be backed out once installed. :roll:
Has anyone else heard of this?

[Chris Mathews]

I ran into a similar problem. The root cause was the DNS name of the server issuing the cookie. Basically, pre-patched IE was not validating the DNS name of the server against the DNS specification and wrongly accepted the cookie (as do most other browsers). Post-patch, IE is now correctly validates and rejects any cookies from a server with an "invalid" DNS name. Since our server had an _ character in its DNS name all of the cookies were being rejected by patched IEs, but no other browsers.
It took a LONG time for me to nail it down to the DNS name... I thought I was going crazy.

[Thomas Paul]

This doesn't seem to be the case. We are accepting and receiving the cookie for awhile without any trouble. Then when we pop up a new window for the user (it's still a page in the same domain) the browser no longer returns the cookie. Using redirection from one JSP to another seems to cause it. We ran a test with an ASP using redirection on a development server and that failed also. Once the user gets the new window, the browser stops returning the session cookie and the user looks like they have never logged on.
Any ideas greatly appreciated.

[Frank Carver]

This has always been a "grey area" in the HTTP/Browser specification (such as it is).
I've had plenty of customers argue with me that they should be able to open different IE sessions in different windows at once, and that my application is "broken" for not allowing it. I seem to recall that Netscape 2 worked like this.
I've seen plenty of applications which baldly assumed that all active browser windows share cookies, history, favourites etc.
One way round this is to build your applications using the "REST" philosophy; either don't use sesions, or encode their IDs in the URL.

[Steve Mutanson]

I am not sure if my case applied to this issue (maybe it is unrelated) --- Theoretically the server should consider the windows opened from a same browser within a certain short period as ONE session, but I found if I use "ctrl+N" to open a new window it is considered as the same session. But if I double clicked IE to open a new one, it is not considered to be the same. I tested this out by testing on some session variable to see how they are changed.

[David O'Meara]

We had the same problem and managed to fix it by using URL rewiting to carry the session ID just for that request, but the powers that be didn't like the session on the URL so we ended up having to live with it.

[Mike Curwen]

Using sendRedirect actually sends one of those 500-level error codes ( i forget the exact one ) that means "the page you're looking for is gone, check this one instead".

Perhaps in their wisdom, IE engineers decide to blow away the cookies for this non-existent page?

Can you confirm that the old cookie is gone from their cache? Or is it still there, but just not being sent? A related question: Do the old windows retain their session, or does using redirect once kill the session for *all* open windows?

Finally, have you used a packet sniffer to see exactly what the browser is sending? Perhaps the cookie information is subtly erroneous. Something you can jump up and down about at Microsoft.

[Eric Pascarello]

As you should know I know Jack about Java, but I will ask you some stuff that might bring so light to the matter, or maybe it is 1 am and I am not tired and I am bored and willing to waste my time!
I know with javascript I can send info to this new window and tell it stuff, can you send info to it and say, hey I am logged on over here and you should be too?
Also is the domain being shifted to a sub-domain? If that is the case, then it is acting like two seperate domains in most cases I have run into. Some times IE does not care)
Pull out some more hair! Then you can shine your head and look like Mr. Clean,
Eric

[Thomas Paul]

Originally posted by Frank Carver:
I've seen plenty of applications which baldly assumed that all active browser windows share cookies, history, favourites etc.

All active windows starting from the same session should be sharing the same cookies. As I said, we have no problem in every version of IE unless you have installed update Q813951. Opening a new window should not cause the session cookie to disappear.
[ April 16, 2003: Message edited by: Thomas Paul ]

[Thomas Paul]

Let me describe the problem a little better. You have window A open and are logged on. You click on a link which using JSP redirection opens Window B which displays a page in the same domain. Window B is not logged in. You close Window B and go back to Window A. Window A is not logged on either. It is as if opening Window B causes the session cookie to be deleted.
This only happens to session cookies. Permanent cookies are still being sent to both windows.
We did do packet sniffing and the browser simply stopped sending the session cookie information once the new browser window was opened.

[William Brogden]

Is it possible that installing that update changed some security settings without telling you? (grasping at straws here...)

[Thomas Paul]

Originally posted by Mike Curwen:
Using sendRedirect actually sends one of those 500-level error codes ( i forget the exact one ) that means "the page you're looking for is gone, check this one instead".

Wouldn't that be either a 301 or 302?

[Mike Curwen]

:roll: yes, that would be the 300-level codes. Sorry about that.

And totally grasping more straws... is page A (or page B for that matter) being cached at all? I'm trying to figure out a way that Chris's note could explain things. If IE doesn't 'recheck' the cookie on a cached page, then it only rejects the 'malformed DNS cookie' when it sees it coming from a page it doesn't have in its cache? But it's a session cookie, right? So the cookie should be newly sent on any session-initiating page, cached or no. But for the sake of trying everything, have you tried this on a machine that has absolutely been cleared of ALL cookies and cached content? IE has behaved weirdly enough with a full-to-bursting cache before. I've cussed and cussed at having a glitchy browser until I try the "oh yah right, THAT'S the problem... DOH!!" solution of emptying my cache.

If you've sniffed the packets and the cookie is not being sent anymore, then I'd confirm the status of the cookie on the client (is it there or gone?). Sorry, you might have answered that by saying "It is as if opening Window B causes the session cookie to be deleted" . So just for clarity.. the cookie is GONE, or 'appears' to the browser to be gone?

After that, I'd say it's time to storm Microsoft. Speaking of which.. is there a reporting mechanism for them? Like a bug parade or something?

[Mike Curwen]

I saw something in the tomcat-user list today that made me think about this post. (Yes, I tend to have that kind of memory). Vague recollections that aren't 100% accurate.

While this bug as described does not explain this post on javaranch, I'll post some details from the tomcat-user email here... as proof that sometimes it is the browser being bad, and not your code. Not that Thomas didn't already know that.

And did this problem ever disappear Thomas?

> -----Original Message-----
From: Craig R. McClanahan [mailto:[e-mail]]
Sent: Thursday, June 26, 2003 1:29 PM
To: David Keyes
Cc: Tomcat Users List
Subject: RE: Cookie handling in IE6 and session handling of tomcat 4.1.24

On Thu, 26 Jun 2003, David Keyes wrote:
> Date: Thu, 26 Jun 2003 08:59:46 -0400
> From: David Keyes <[e-mail]>
> To: Tomcat Users List <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Cookie handling in IE6 and session handling of tomcat
> 4.1.24
>
> IN GENERAL:
>
> For any two domains, A and B, if B is a subdomain of A (e.g., B.A),
> and if two different J2EE app servers are hosting those domains, the
> following will be true, assuming that the two appservers create
> session cookies that are identical except for the domain (note that a
> cookie consists of: name, domain, path, expiration):
>
> * If a user, running Internet Explorer, uses J2EE apps running on both
> domains, causing a session to be established on both domains
> simultaneously, the client accessing the application running in domain
> B will not be able to access a session established in domain B.
>
> This is due to the fact that IE orders cookies from least-specific to
> most-specific WITH RESPECT TO DOMAIN in an HTTP request. ANY app
> server that looks for the FIRST cookie named JSESSIONID will be
> susceptible to this problem.
>
> EXAMPLE:
>
> In our case, tomcat was serving up JSPs on "x.com", causing a J2EE
> servlet session to be created when that page was loaded. Immediately
> after hitting x.com, "w.x.com" was being loaded, which also caused a
> session to be created. Both sessions were being identified by cookies
> set in the client browser. The cookies both had an ID of JSESSIONID,
> with an identical path. The only difference between the cookies was
> the domain (one was "x.com", and the other was "w.x.com"). When
> interacting with the app on w.x.com, each request included an HTTP
> header specifying client-side cookies. In that header, the JSESSIONID
> created by x.com was ordered BEFORE the JSESSIONID created by w.x.com.
> The appserver on domain w.x.com was consequently attempting to find
> the session that had been created on x.com, and since it could not,
> was creating a new session with each request.
>
You probably want to address this as a bug report against Tomcat:
http://nagoya.apache.org/bugzilla/
However, I can't see a lot of motivation to make Tomcat disobey the specs just because IE does.
The real issue is that the incoming cookies only have names and values; there is no extra information with which to disambiguate them. Changing the current "take the first one" policy woud break Tomcat for all users on all browsers when you have context paths nested (instead of or in addition to domains), so it is not a general purpose solution.
But it's an issue for the Tomcat developers to hash out. I'm not an active one any more (although I try to keep an eye on things there).
> Dave Keyes
Craig

[Derek Clarkson]

Hello everyone, I just found this posting. I have had the same problem. Opening a window causes the session to change. BIG NOTE: I have reproduced this in FireFox - therefore it is NOT IE specific.
I solved it by writing a cookie for JSESSIONID explicitly setting the domain to our domain and the path to the root path "/". It seems these two parameters are required to solve this.
Interestingly enough, when I monitored the cookies being used through out the program, I would regularly see two cookies called JSESSIONID. One my custom built cookie and the other being Tomcats session tracking one. What interesting is that despite setting the domain and path, both cookies returned nulls in these fields.
I'm still trying to figure out how Tomcat sees a new window as a new session, although within my app, we are also loading a jsp from a different path. This may be part of the problem as my research indicates that tomcat regard path changes as being context changes and therefore issues a new session.
Hope this helps.
Derek.

[Steve Leach]

How are you forcing a new window ? Using "frame='_new' in the link tag ? Or using JavaScript ?