On Jan 6, 2008 10:58 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > [...] > The situation is a little subtle: by default, we use the same session > cookie name for every Django site. You can change that. In fact, when I > first saw this message, I couldn't repeat the problem because the case I > tested it on had the session cookie being called something unique. > > Anyway, with the default name, you will sometimes be submitting a > session cookie that comes from another Django site. The session id won't > match anything in your database, so the subversion version of Django > (with the new pluggable backends ... this shouldn't be a problem in > 0.96) will save a new session to the database. However, it wasn't > marking this new session as "modified", so the HTTP response wasn't > sending back a set-cookie header. Thus, on the next request, you'd get > the same bad session id, a *new* session entry would be created... > rinse, wash, repeat. > > This would happen even if you weren't specifically using the session on > a particular request (in fact *only* in that case -- because if you > wrote to the session, it was being sent to the user each time). So > [7001] makes sure the new session cookie is sent back to the user as > well. >
Just managed to put on Trac some mental notes I had made about topics being discussed on the mailing lists and tickets I had seen being opened and found this isue had already been reported as bug #5593. I'm closing it and leaving a link to this thread there. Regards, -- Ramiro Morales --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
