Hi Anton, ak schrieb: >> so it doesn't get us any real improvement in security > > James, there is a concept of 'fool proof'. Real hackers may do many > things. But current model allows even 10 year old kids to be hackers. > This is just against them. There is no ability to protect all sites > with ssl and I would not like a neighbor's son could read my email > because he got my session id by running simple ethereal > > >> I'm not saying I'm against separating insert and update in the ORM, >> though > > Have you ever looked in my code ? There are no hacks of ORM, there is > just a different sessions table design where session id is not anymore > a primary key but just an unique key. Primary key is a separate field > and this approach allows us to use existing ORM to do things correct > way where session collision is impossible at table level, so > impossible by design. > And again: I am not voting against improving if IDs generation, I > think these problems should be solved both.
I like that your code guarantees that you don't issue a session id that is still in use. I don't care how this is achieved, be it with a separate id or with using get_or_create, as long as it works without leaving holes as the current implementation does. Is there a good reason for the current implementation? But I don't like that newsession insists on checking the IP. You argue that it protects against an attacker who can sniff the session id and replay it. But wouldn't a hacker who is able to observe the traffic simply sniff the password, too? I see problems with IP checking (as mentioned in posts before), but no real added security. 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. Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---