Problems with jsessionid and Internet Explorer

We are running on CF9.0.1, Java 1.6.0_25, and Win2003 Server. Our application uses J2EE sessions instead of Coldfusion session management.

Apparently, IE (6 through 9) has a problem where it can confuse the domain and sub domain of a cookie or session.

Here is the problem:

• A user logs into a session at domain.org (not www.domain.org).  This  user gets a session cookie which (surprise!) can be read by any  subdomain of domain.org.
• The same user links to a second application at subdomain.domain.org.
• The user logs in, thus setting a second session cookie. This login will work!
• But trouble is just ahead; the moment the user browses anywhere, the  application may fail. MSIE returns the domain.org session cookie first,  not the subdomain.domain.org cookie.

This was only a very rare issue for years until the last month. Now we get calls about logout on the very first click after logging in to our application

on a daily basis. The problem is exclusivly IE. All other browsers work fine. Typically, a user starts at our homepage at https://www.domain.com which links them to https://secure.domain.com where they login, get to their homepage, and are logged out on the next page request.

We can only randomly reproduce this problem in our office. It is very intermittent and requires some perfect storm of links and redirects which we cannot replicate. But, when it does happen, we are able to view the headers using Fiddler and can verify this is the problem. Somehow, IE gets into a state where where it is sending two jsessionid values in the header:

...

Connection: Keep-Alive
Pragma: no-cache
Cookie: JSESSIONID=8430bacbee6307aa542a5a92c50611b5d140;JSESSIONID=8430ba6416114e4ea58e76274a155064751e

...

The first jsessionid is from the first subdomain and is not valid at the second subdomain. The second jsessionid is the valid one from the second subdomain.

When a session is created a Set-Cookie header like this is sent:

Set-Cookie: JSESSIONID=8430bacbee6307aa542a5a92c50611b5d140;path=/

Now what should happen is IE should be able to assign that session cookie to the domain it came from and only send it back with requests from that

same domain. But its not. For some reason, sometimes is sends all jsesssion cookies from the top level domain (.domain.com) with all requests

hence the two values in the header.

JRun apparently does not know how to deal with this. Other servelet containers (like Tomcat) will look at the first jsessionid see it is invalid and keep trying until it finds a valid session id or runs out of values. JRun tries the first one it finds, sees its invalid, and sends a new session id back with the response. This causes the browser to update the second jsession id while the first remains static and it continues in this loop indefinetly until all cookies are deleted and only a single jsessionid is set at the proper domain.

In CF9, the domain attribute was added to cfcookie where you can explicilty define the domain as well as the path the cookie is good for.

There is no such option when the jsessionid is created. There is a configuration variable for cookie-domain in the jrun-web.xml file but that would

hardcode it for all cookies on the server and our app runs under www and secure for three different domains on each box.

I have tried setting the jsessionid with an explicit header directive using <cfheader> like this:

<!--- create the header value --->
<cfheader name="Set-Cookie" value= "JSESSIONID=#SESSION.SessionID#;domain=.#CGI.SERVER_NAME#;path=/">

in the onSessionStart() method but it just causes two Set-Cookie headers to be sent:

Set-Cookie: JSESSIONID=8430bacbee6307aa542a5a92c50611b5d140;domain=.domain.com;path=/
Set-Cookie: JSESSIONID=8430bacbee6307aa542a5a92c50611b5d140;path=/

There also is no way I've found to programmatically delete both jsessionids as the browser does work properly in that it only deletes the cookie from the domain of the response. It still continues to send the old jsessionid from the first subdomain with each subsequent request. The only solution is to manually delete cookies from the browser and restart it.