Hey mrts, On Apr 5, 2:31 pm, mrts <[EMAIL PROTECTED]> wrote: > The cookies are already signed. Session data + > settings.SECRET_KEY is md5-digested and tampering raises an > exception. So in that sense the sessions are already secure.
Sorry, I didn't mean "secure" in the sense that someone can alter the data. I meant secure in the sense that (a) there is a guarantee of no collisions and (b) someone else cannot easily hijack the session. I believe that Graham said was that sessions aren't "threadsafe" because two sessions could have the same key (although it's very unlikely). In this way, sessions aren't multi-process or multi-server safe either. (I would venture to guess the projects that have problem with this level of concurrency are also the projects that have multiple servers.) There was talk long ago of using db-level locking (either through sequences or transactions) to ensure two sessions cannot create the same ID. From what I can tell, this was deemed not a good fit for Django. Since then, the session interface has changed so there is no need to convince the Django core developers that every Django project needs these features. You can write your own app that supports this session key safety and a few other session-based "controversial" features that are needed for safety. (And if the backend is good, it might be merged into trunk as a non-default backend.) Cheers, Mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
