This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
my problem is tomcat continue to reuse a range of jsessionid or "a group" of jsessionid (not related each other), during the day:
if i check the log i can see it sometimes reuse the same session id "XYZ" after 5 seconds it has been invalidated.
I can understand it could reuse the same session during a week, if i had 2milion users a day, but it's reusing the same session id within the SAME day...
Is there a way to change the management of the sessions without extending or replacing the standard tomcat manager?
The session ID is a hash key, and it would be a major problem if it wasn't generated with a unique value for each session.
However, just because a session was invalidated doesn't mean that the session ID instantly evaporates. The session ID is being passed back and forth between client and server, and until both sides of the conversation stop sending it, it's going to pop up in various places.
However, once the session has been invalidated, the session ID will become a hash key to nothing. Even though the jsessionid is in the URL, it won't be attached to anything.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Mar 15, 2012
>Welcome to the JavaRanch, Diego!
>I suspect that things aren't as they seem.
>The session ID is a hash key, and it would be a major problem if it wasn't generated with a unique value for each session.
i've not this problem
>However, just because a session was invalidated doesn't mean that the session ID instantly evaporates.
> The session ID is being passed back and forth between client and server, and until both sides of the conversation stop sending it, it's going to pop up in various places.
>However, once the session has been invalidated, the session ID will become a hash key to nothing. Even though the jsessionid is in the URL, it won't be attached to anything.
uhm, it seems i've a problem, but it's slightly different:
there are NEW session where the ID used is the same of a previously closed session. This means if someone had it's old session closed but the browser open, he could click BACK finding it's session NO MORE invalidated, because the ID now points to a NEW session (i'm using a cookie to check this problem and prevent it: when it happens i invalidate the session)
The thing i can't understand is how it could be tomcat has the need to reuse many same ID during the day.
I just looked at some of the Tomcat code, and this is my best guess. You might want to try to debug to confirm.
As far as I can tell, Tomcat uses a class called StandardManager to create sessions. This class extends ManagerBase which does the real work of generating the session ID. ManagerBase has a method called generateSessionId that calls a method called getRandomBytes, which in turn uses a system file called "/dev/urandom". This is a system file on Linux that generates a random number, and it can recycle random numbers. This could be the reason your session ids are getting recycled.
You'll need to debug this to confirm, but if you want stronger random number generation, you might want to look at using/dev/random. Fortunately, devRandomSource is protected, so might be able to just override it
Joined: Mar 15, 2012
>You'll need to debug this to confirm, but if you want stronger random number generation, you might want to look at using/dev/random. Fortunately, devRandomSource is protected, so might be able to just override it
I was reading Tomcat sources, to understand what it does, but i've not reached that point of the source.
There are 2 properties in RandomManager that may be overridden. One is randomFile, which defaults to /dev/urandom, and the other is randomClass, which defaults to an internal pseudo-random number generator.
Before getting too involved in that, however, I repeat that the session ID is a hash key, and when a session is invalidated, the corresponding session object is purged from the session cache. Therefore, the only real problem with repeating session IDs is that if they really are re-appearing that frequently, it increases the probability that someone could reference someone else's session, since a randomly-selected session ID would normally have a low probability of matching one of the keys in the session cache.
Reading code for cases like this is a bit risky, since code can tell you how something's being done, but not why, and if the code is sufficiently dispersed, it can even be difficult to be sure "what".
I'm pretty sure I recall having seen some docs on session ID generation and random number generators in the Tomcat docs, so I recommend looking for them before plunging too deep into the code.
It also wouldn't be a bad idea to ask the actual Tomcat developers in the apache tomcat developers forum.
Under ordinary circumstances, the default mechanisms are more than sufficient, however. Tomcat has had a long time to get the mechanism down right.
Actually, any technique that prevents session hijacking will help you. Rather than try to "fix" tomcat's session id generation, you might want to look at strategies for preventing session hijacks. I'm not an expert here, but from what I know, the techniques you could use are
a) "Remember me" token - Basically, whenever a user logs in for the first time, an encrypted token is stored in a cookie and the session. In every user, you verify that the token in the cookie matches the token in your session. This has the benefit of providing a "remember me" feature. You could persist the cookie in your user table, and if an unauthenticated request comes in with the cookie, you authenticate the user if the cookie matches.
This solution will work for you, but won;t completely prevent session hijacking attacks (unless your site is on SSL)
b) Page token
For each link inside your rendered HTML, you generate a random pageToken. You keep these pageTokens in your session. Whenever a request comes in you verify that the pageToken matches
This will also solve your problem, but it's much more difficult to implement, because you need to now change all the code that puts a link on the HTML to put the token.