Michael Radziej wrote:
> But something else must go wrong in your case, as the chance to get the
> same session ids should be so tiny that you really shouldn't reports
> from your users. Comments say that the random number generator is
> seeded when the server process starts, and it's seeded with the current
> time. Isn't that bound to fail with multiple processes that start at the
> same time? I don't know much about the random module, though.
I've just recalled a case... I was using Django's randomly generated
passwords and it worked fine under mod_python. Then I switched to
FastCGI and from some moment *all* passwords started being generated
absolutely equal. The thing was that mod_python was reloaded from time
to time by Apache (using MaxRequestsPerChild) and flup-based FastCGI
were never reloaded. Over long time Python's random generator just
degenerated into giving out exact values (this was Python 2.4 on Debian).
I've solved the problem by manually re-seeding the generator based on
time and couple of other request related data. This now works about half
a year without problems. In our session case this can be as simple as:
random.seed(str(datetime.now()) + str(id(request)))
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
