The issue is related to cookie path, and not with domain No I understand. 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.The example on the course looks like this: Pros: it's simple, very much like you would do it in older Spring-MVC and other less capable frameworks.Cons: it's messy, exposes your clean controller to the Servlet API and needs null checking after you've called get Attribute.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.In any event, the actual value of jsessionid on either client or server should not be used by any application code. Now, although HTTP session gets clean, JSESSIONID remains with the same value.
When you invoke session.invalidate() on the Http Session, it detaches the session from Tomcat's hashtable. 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.
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.
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.