This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I assume they are a hash of something, but does anyone know more about the algorithm? Like which pieces of information go into the hash, and within which timeframe IDs could conveivably collide? Any links are appreciated as well.
just being curious. lets say several users (user A, B, C, D and E) interacted with server.
and then, the server is restarted, so all sessions are all destroyed.
then comes user F and F also got new session. my question is, is it possible the newly generated session id to be the same as sessions still retained by user A - E?
if it is, then this would be a security breach as user other than F theoretically will have access to F's data.
is this the case with tomcat?
Actually, the default behavior for recent versions of Tomcat if the server is restarted is that the sessions persist over the restart (they're stored in the work directory as ".ser" files).
The sessionid-generating algorithm, like all hash algorithms can potentially come up with an identical ID, but the whole point of designing the algorithm is to minimize that possibility. I like Brockschmidt's quote about the chances of 2 GUIDs generating the same as "about as likely a a bunch of atoms out in space suddenly rushing together to form a small walnut".
Incidentally, if you switch from normal to SSL security in Tomcat, the session remains, but the old jsessionID is discarded and a brand-new one is generated. It still refers to the same session, but that way people cannot tap into secured communications using the unsecured handle that was public visible (unencrypted) - it's no longer attached to anything.
An IDE is no substitute for an Intelligent Developer.