wood burning stoves 2.0*
The moose likes Tomcat and the fly likes JSESSIONID value is not changed on invalidating session Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "JSESSIONID value is not changed on invalidating session" Watch "JSESSIONID value is not changed on invalidating session" New topic
Author

JSESSIONID value is not changed on invalidating session

Joao Longo
Greenhorn

Joined: Jan 04, 2012
Posts: 14
Hello people!

I needed to change JSESSIONID's domain to ".something.com" in a context.xml file:



After that, when I perform a httpSession.invalidate() the session is reset but JSESSIONID value does not change.

I'm using Java 7, Spring MVC and Tomcat 7. I also tried to remove the JSESSIONID cookie manually, but it seems that Tomcat or Spring are not letting I change its value.

This may difficult troubleshooting on my system. I'd like to know if it's possible to change this behavior either on Spring or in Tomcat.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

I'm not following you.

If you change the cookie domain in a Tomcat Context, you would have to restart the entire web application. In fact, Tomcat will generally sense the change and do that automatically on its next timed scan for changes.

You sound like you expect that you can change this value in the middle of running the application.


Customer surveys are for companies who didn't pay proper attention to begin with.
Joao Longo
Greenhorn

Joined: Jan 04, 2012
Posts: 14
I think the situation is not clear. The JSESSIONID domain was changed and Tomcat was restarted.

When a user enters on the app, he receives a JSESSIONID, e.g., "12345678". The problem is that when this user leaves the app (calling session.invalidate()), the JSESSIONID value does not change, it remains "12345678", but the session values was reset.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

It is still not clear.

The JSESSIONID cookie (or URL suffix) is a name/value pair, whose name is "jsessionid" and whose value is a "random number". That "random number" is generated to serve as a hash key used by the J2EE server (Tomcat) to retrieve the HttpSession object for that particular user. Since it is "random", it exposes no details about the session itself to unfriendly listeners.

When you invoke session.invalidate() on the HttpSession, it detaches the session from Tomcat's hashtable. The jsessionid itself then becomes meaningless. I wouldn't expect the server to send further jsessionid cookies back to the client, although without checking, I don't know if the response to the request that destroyed the session also sends back cookie-destruction information, and if it doesn't that would leave the jsessionid cookie on the client, even though it was meaningless.

For a non-secure session, it's probably OK if a new session request would create a new session instance and bind it to the old session ID if the client continued to send down the original cookie. For https, it would be a security issue, though. Tomcat keeps the session but changes the jsessionID when it shifts from http to https transport. Which means that the jsessionid cookie it sends back via SSL has a different value.

In any event, the actual value of jsessionid on either client or server should not be used by any application code. That's a good way to end up in a lot of trouble.
Joao Longo
Greenhorn

Joined: Jan 04, 2012
Posts: 14
Hello

I got your point. In fact, I need one of the two behavior below:

1. When I call session.invalidate(), JSESSIONID cookie is removed
or
2. When I call session.invalidate(), JSESSIONID cookie value is changed

The option #2 was happening before I change JSESSIONID's domain to ".something.com".

Now, although HTTP session gets clean, JSESSIONID remains with the same value. This means that the next time (without close the browser) user enters on my app, JSESSION will have the same value! This is disturbing troubleshooting.

I've already tried the following workarounds without success:

1. Call request.getSession(true) after I call session.invalidate() -> session is created with JSESSIONID value equals to previous one
2. Remove the JSESSIONID cookie explicitly -> it doesn't work
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

I still do not comprehend.

The jsessionid and its associated cookie and/or URL suffix do not belong to you nor to the application program. They are the exclusive property of the client and the server. The server creates/updates/removes it, the client stores it and transmits it. Neither you personally nor your application code should even care if it exists or not or even if magic elves are the mechanism that associates a given client with a given server session rather than cookies or URL rewriting. If the server wishes to discard a session but not explicitly remove the cookie, it has the right to do so. According to a quick check on my client, the jsession cookie's natural lifespan extends until the client itself is destroyed. Or until an explicit clearing of cookies is done by the client's security tools, whichever comes first.

As I said before, any attempt by client or server application code to explicitly work with jsessionid is more likely to introduce problems than to solve them. It's better to devote time to more productive concerns.
Joao Longo
Greenhorn

Joined: Jan 04, 2012
Posts: 14
I don't agree completely with the sentence: "It's better to devote time to more productive concerns". I had a requirement to change JSESSIONID's domain to ".something.com" for a reason X. But this has caused the issue I reported on this bug.

This may difficult troubleshooting on my system. So, my question is if there is some configuration on Tomcat to do not keep JSESSIONID value the same when invalidation session. I don't want to change JSESSIONID in app. I want Tomcat/Spring takes care of it as before I've changed its domain.
Joao Longo
Greenhorn

Joined: Jan 04, 2012
Posts: 14
I found the problem in Tomcat's documentation:

Note: Once one web application using sessionCookiePath="/" obtains a session, all subsequent sessions for any other web application in the same host also configured with sessionCookiePath="/" will always use the same session ID. This holds even if the session is invalidated and a new one created. This makes session fixation protection more difficult and requires custom, Tomcat specific code to change the session ID shared by the multiple applications.

The issue is related to cookie path, and not with domain
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

No I understand. I have been subject to this fault as well. You asked a question with a pre-conceived answer and you asked it in terms of your answer.

The real question doesn't have to do specifically with manipulating jsessionid cookies, it has to do with how webapps share sessions.

I could review the situation in those terms, but since you apparently need to know what you need to know, I won't bother. If I read it correctly, however, this is a case where a superior context ("/", or the root context) will override inferior contexts ("/abc", "/def").

I think that there are some further tricks you can do to fine-tune what webapps share what sessions, but that would require reading the manual. I'll leave that honor to you.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: JSESSIONID value is not changed on invalidating session