Win a copy of Event Streams in Action this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Tomcat Returns Different Session Id

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We are developing an app using Ajax on the client side and Tomcat on the server side. We have run into an issue with Tomcat returning different session ids between requests. We created a simple test app which sends Ajax requests to Tomcat. What we have found is:

1) sending multiple Ajax requests independently of each other to Tomcat results in different session ids, which is to be expected

2011/1/21 10:28:52.757 200 url=test/fetchOne sessionId=C7E2BCF7266EA208FC049F0F4A1848B5
2011/1/21 10:28:52.758 200 url=test/fetchTwo sessionId=B3D17000A4A481DB076547D8217493B6
2011/1/21 10:28:52.758 200 url=test/fetchThree sessionId=98C25FAB42F957A3BECA3C65917CE1B6

2) sending a single Ajax request and then sending the remaining requests after the first one has responded, we get the same session id across requests, which is expected

2011/1/21 10:28:24.470 200 url=test/fetchOne sessionId=A8A221C228367CAA2FE51E15F66210B7
2011/1/21 10:28:27.253 200 url=test/fetchTwo sessionId=A8A221C228367CAA2FE51E15F66210B7
2011/1/21 10:28:27.253 200 url=test/fetchThree sessionId=A8A221C228367CAA2FE51E15F66210B7

3) for both 1) and 2) above, if we add authentication (BASIC, CAS, etc...), initially we get different session ids across the Ajax requests, but eventually tomcat will return the same session id

2011/1/21 10:29:54.342 200 url=test/fetchOne sessionId=1C8A8255ADAA768E46124484C0C4D197
2011/1/21 10:29:56.597 200 url=test/fetchTwo sessionId=DE3AB5132A3B7F297D6E0CE2CE211C25
2011/1/21 10:29:56.597 200 url=test/fetchThree sessionId=B24A306F2D77A7B2812D6FFD686DC0E2
2011/1/21 10:29:57.813 200 url=test/fetchOne sessionId=2B9F6B5663EB205DA12C162512553831
2011/1/21 10:29:57.820 200 url=test/fetchTwo sessionId=2B9F6B5663EB205DA12C162512553831
2011/1/21 10:29:57.821 200 url=test/fetchThree sessionId=2B9F6B5663EB205DA12C162512553831

This seems to be happening with Tomcat 6.0.24 and up (including 7.0.8). This works as expected with Tomcat 6.0.20. We also tested using Jetty and it works as expected.

Anyone seen this before or have any ideas? Thanks.
 
Bartender
Posts: 20934
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The larger question is "Why do you care what the exact session ID is?"

The session ID is nothing more than a hash key that the server uses to locate the HttpSession object for a user request. There's nothing you can do with this value, since the key is only useful for Tomcat to get data from one of its internal hashtables and attach it to the HttpServletRequest object that it's constructing. What its actual value is from request to request is only important if something fails and the HttpSession object cannot be found by Tomcat.

In actual practice, I think that current versions of Tomcat will consistently use the same sessionID, with 2 very important exceptions:

1. When you switch into SSL mode, a totally new sessionID is assigned.

2. If you destroy an existing session (session.invalidate()), the next time a session is needed, it will be created with a new hash ID.

Regardless, the only time any of this should matter to you is if you're not getting the session object you're supposed to be getting.
 
Jason Christian
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We care about the session ID because once authenticated, the authentication is tracked in the session, instead of having to hit the CAS server for every request. With Tomcat creating new sessions, it messes that up.

Come to find out, the issue is that Tomcat was modified to help prevent session fixation attacks. By default, a new session id is created on authentication. This started with 6.0.21 (Context configuration changeSessionIdOnAuthentication).
 
Tim Holloway
Bartender
Posts: 20934
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jason Christian wrote:

Come to find out, the issue is that Tomcat was modified to help prevent session fixation attacks. By default, a new session id is created on authentication. This started with 6.0.21 (Context configuration changeSessionIdOnAuthentication).



That's case #1 in my list.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!