On 14.02.2014 14:27, Mark Thomas wrote: > On 14/02/2014 13:15, Rainer Jung wrote: >> I ran into a special requirement for the session id generator >> (uniqueness of session id for a longer time interval). While I think >> that the requirement needed isn't a useful general purpose extension, I >> stumbled over the fact, that the SessionIdGenerator class is not pluggable. >> >> Would it make sense to introduce a new interface for the session Id >> generation, probably including setJvmRoute(), setSessionIdLength() and >> generateSessionId(), letting the current implementation be the base >> implementation, probably switching getRandomBytes() to protected, and >> allowing to set the implementation class in ManagerBase - or the Manager >> interface (trunk)? >> >> I haven't worked it out in detail, but it looks easy to do and useful. >> >> WDYT? > > I'm struggling to understand the use case. Are you saying the current > implementation generates collisions?
Yes. But only over time, not concurrently. So some session ID used some time were again generated on later days. The rate was low, about one out of 100.000 IDs were generated again during the next 30 days. I don't see a problem here per se, but the application required the IDs to be unique over an extended period of time. > That would be bad given that > SecureRandom is being used. Not sure, whether the above rate is totally unexpected. It could have used /dev/urandom, so might depend on total system behavior. > Ignoring the previous question, why can't the requirement be met with a > custom implementation of SecureRandom? Just because I haven't thought of that :) Will check. One thing that comes to my mind is that the session id generator encodes the random bytes. Making IDs more unique for an extended period of time will end up replacing some of the random bytes by other data. That limits the randomness. I was hoping to compensate for that by using an extended setof characters to encode the ID instead of simply hex like it is now. So at the end, I can squeeze the additional info plus enough random bytes in it. AFAIR that changed encoding would mean I have to change the session id generator. > If the requirement is to be certain that a duplicate session ID is not > generated I'd use a custom Manager and check the returned ID against > those currently in use request a new one in the highly unlikely event of > a duplicate being returned. That's already done by our StandardManager. It is not about the ones currently in use but about ones that had been used during the last say 30 days. There's a database I could check against, but since very few "duplicates" seem acceptable I prefer to reduce the number of duplicates by adding time information to the custom session id shrinking the window of possible duplicates. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
