On 3/13/07, ak <[EMAIL PROTECTED]> wrote: > 1. REMOTE_IP. I think it is a good idea to check it. Load balancers > acts as proxy servers. Every web server has a module that allow to > restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is > called mod_rpaf. And ofcourse it's very easy to make REMOTE_IP > checking code to be disabled or enabled via settings.py, just like it > is in php, such modification is quite simple.
I'm still wary of this -- again, it doesn't do anything to prevent man-in-the-middle, and it introduces complexity and -- if we're worried about session collisions -- introduces a whole new class of bugs when you have a bunch of people behind a NAT or firewall who all, from the POV of your server, have the same IP address. > 2. In my installation I use lighttpd and django as preforked fastcgi > server, python 2.4. It's hard to reproduce such things but they _do_ > happen. One can say my installation is broken but I think it's rather > a hole in django if it allows such things to be ever happened. I think we definitely need to tighten up the time between selecting a session key and shoving the session into the DB -- I'm thinking along the lines of using get_or_create and retrying until you get back a True creation value from it (that way you don't have to do anything else -- the session is already in the DB when get_or_create returns. But I'm still worried about the apparent fact that this is all coming from key collisions, because what it points to is not a race condition at the database level -- what it points to is bad randomness. Python's random-number generator uses the Mersenne Twister, and in Python 2.3 it seeds itself with the current system time (and in 2.4 it tries system-supplied randomness facilities first, then falls back to system time). I'm not an expert on randomness by any means, but the problem we have here is the same pair of random numbers being generated at the same time or within a very short time of one another, and my first inclination is to look at the fact that we're using a deterministic RNG seeded -- by default -- with the system time. So instead of trying to ensure safety at the database level (because, frankly, unless we go to extremes we're not going to manage that), why not look at better seeds for the RNG and solve the real problem? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
