> From: David Delbecq [mailto:[EMAIL PROTECTED]
> Those are generated by taking the first 16 characters of
> the md5 sum of a random byte[16].
Interesting. Note that although the existing code makes considerable
effort to ensure this *is* random, a number of factors can apparently
decrease the randomness:
- Running on Windows, which removes the ability to use /dev/urandom;
- Running without APR, which reduces the set of values that getEntropy()
can return to the set of valid addresses of Java objects on the Tomcat
heap at the time (more of an issue with a small webapp);
- Best-practise time synchronisation between servers plus running on
operating systems with relatively large millisecond clock granularity
(like Windows on x86, which I think still has a 20ms granularity), which
can result in the major entropy source (the millisecond clock) being
closely synchronised between the servers;
- Restarting the containers and then opening for business via a load
balancer, which may result in the first requests coming in to multiple
servers at very similar times - particularly a problem if the clocks are
closely synchronised, as it drastically increases the chance of the same
millisecond clock value on multiple servers.
If you ever happen to get the same seed between two servers, you're
seriously hosed - I *think* the way the code works, those systems will
generate and continue to generate duplicate session IDs until one is
restarted.
I don't know how much of an effect these factors have in reality, but I
think I'd prefer to run on some OS other than Windows and/or enable APR
if I were planning to rely on the session IDs. This is based on a
relatively superficial analysis of the code; it may be that there are
built-in defences against the problems described above that I've not
found!
- Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
