#29971: Sessions setting vary cookie without providing a cookie
-------------------------------------+-------------------------------------
Reporter: Jd Collins | Owner: Jd
Type: | Collins
Cleanup/optimization | Status: assigned
Component: contrib.sessions | Version: 2.1
Severity: Normal | Resolution:
Keywords: Sessions Vary | Triage Stage:
Header Cookie | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Jd Collins:
Old description:
> While reviewing process_response I believe the code is trying to
> accomplish the following things:
>
> 1. Determine if the session has been accessed.
> 2. Determine if the session has been modified.
> 3. Determine if the session is empty.
> 4. If the session cookie is in the cookies but is empty remove the
> session cookie.
> 5. Else if not 4. then if the session has been accessed then patch the
> vary header to add Cookie.
> 6. If the session has been modified or settings dictate that we always
> save the session and the session is not empty then we setup some cookie
> attributes, save the session, and set the cookie in the response.
> 7. Return the response.
>
> Possible issues in the current behavior:
>
> 1. As reported in 29471, step 4 in the current behavior is responding in
> a way that sets the cookie to a blank value and expired but not setting
> the vary on cookie so this response can be cached for a requests causing
> authenticated sessions to be logged out.
> 2. Step 5 in the current behavior, accessed is always True when using
> auth as a result of: django/contrib/auth/middleware.py in get_user. I am
> not sure how accessing the session alone is enough reason to vary on
> cookie regardless of why it was accessed?
> 3. Step 5 in the current behavior, adds the vary cookie header even if
> the session is empty and will not be setting a cookie. This is
> problematic for caching since you are requiring a unique session based
> cache even if the session is empty.
>
> Proposed behavior:
>
> 1. Determine if the session has been accessed. (Not sure if this is
> providing much value for a vary header perspective but leaving it).
> 2. Determine if the session has been modified.
> 3. Determine if the session is empty.
> 4. If the session cookie is in the cookies but is empty remove the
> session cookie. Also set the vary cookie to address potential issue #1.
> 5. Else if the session has been modified or settings dictate that we
> always save the session and the session is not empty then we setup some
> cookie attributes, save the session, and set the cookie in the response.
> Also set the vary cookie.
> 6. Else if the session is not empty the set the vary cookie.
> 7. Return response.
>
> Related Ticket(s)
> https://code.djangoproject.com/ticket/29471
New description:
While reviewing process_response in django/contrib/sessions/middleware.py
I believe the code is trying to accomplish the following things:
1. Determine if the session has been accessed.
2. Determine if the session has been modified.
3. Determine if the session is empty.
4. If the session cookie is in the cookies but is empty remove the session
cookie.
5. Else if not 4. then if the session has been accessed then patch the
vary header to add Cookie.
6. If the session has been modified or settings dictate that we always
save the session and the session is not empty then we setup some cookie
attributes, save the session, and set the cookie in the response.
7. Return the response.
Possible issues in the current behavior:
1. As reported in 29471, step 4 in the current behavior is responding in a
way that sets the cookie to a blank value and expired but not setting the
vary on cookie so this response can be cached for a requests causing
authenticated sessions to be logged out.
2. Step 5 in the current behavior, accessed is always True when using auth
as a result of: django/contrib/auth/middleware.py in get_user. I am not
sure how accessing the session alone is enough reason to vary on cookie
regardless of why it was accessed?
3. Step 5 in the current behavior, adds the vary cookie header even if the
session is empty and will not be setting a cookie. This is problematic for
caching since you are requiring a unique session based cache even if the
session is empty.
Proposed behavior:
1. Determine if the session has been accessed. (Not sure if this is
providing much value for a vary header perspective but leaving it).
2. Determine if the session has been modified.
3. Determine if the session is empty.
4. If the session cookie is in the cookies but is empty remove the session
cookie. Also set the vary cookie to address potential issue #1.
5. Else if the session has been modified or settings dictate that we
always save the session and the session is not empty then we setup some
cookie attributes, save the session, and set the cookie in the response.
Also set the vary cookie.
6. Else if the session is not empty the set the vary cookie.
7. Return response.
Related Ticket(s)
https://code.djangoproject.com/ticket/29471
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29971#comment:2>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/070.6fee30a65263b755cd394a822c8ef03d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
