#11506: session.flush should not delete the old session
----------------------------------+------------------------------------
Reporter: Glenn Maynard | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
----------------------------------+------------------------------------
Comment (by Ramon Saraiva):
Replying to [comment:8 Tomek Paczkowski]:
> Patch no longer applies. As the ticket is 5 years old it would be worth
checking that the problems still occurs.
This seems to be currently happening in our production environment and it
was extremely difficult to reproduce. I'll try to explain our use case as
an attempt to revive this issue.
We have a few ajax requests that are initiated simultaneously, and one of
them is responsible for logging in a user. Depending on how requests are
distributed in nodes/processes/threads, if any of the requests that have
the same session id cookie get processed a bit after the one that logs the
user in, Django will generate a response setting the session id cookie to
an empty value. This ends up making the application lose the login state
and any data that was previously written to the session.
When Django is logging the user in, a new session id is generated and the
data is moved over to this new location. Everything works well despite the
fact that Django deletes the old session id from the session engine (i.e.:
cache), making any attempt to load data from the old session id result on
a new session id or simply a blank session id set cookie.
To replicate that, I created 3 views:
* `GET /` returns an empty HttpResponse (this will be used to simulate the
blank session id set cookie response)
* `GET /session/` adds a simple value to `request.session` and generates a
`sessionid`
* `POST /login/` logs an user in
1. Create a single request to `/session/` generating a new sessionid
cookie
2. Create multiple async fetches to `/` while having 1 of them posting to
`/login/`
3. Anytime that one of the `/` requests get processed after `/login/` was
processed, your sessionid cookie is gone
4. If you delay the `/login/` request, a new sessionid is received and
everything works as usual
This can potentially be fixed in the application itself, by removing
concurrent requests that happen in the same time that someone is logging
in, but there might be ways to avoid that within the framework, maybe
avoiding to delete the session key from the engine as soon as a new
session key is generated. Or allowing developers to customize whether they
want the previous session to actually be removed from the engine, allowing
them to simply let sessions expire.
Warnings would also be helpful to speed up the debugging process of
something like this.
Would love to know what you all think about this,
Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/11506#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070183e931bdcc-003f5aab-c908-4598-b32c-ee578f99cbb0-000000%40eu-central-1.amazonses.com.
