#19649: Cookie message storage does not set Vary: Cookie
------------------------------+--------------------------------------
Reporter: carljm | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 1.4
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Description changed by carljm:
Old description:
> The cookie storage backend for contrib.messages does not set Vary: Cookie
> on the response, which means that (in the absence of CSRF protection or
> sessions or other bits of Django that are likely to set Vary: Cookie) it
> is possible for users behind a cache to miss messages intended for them,
> or even for a cache to store a page with a message intended for a single
> user on it and then serve that page to other users.
>
> In practice, it is quite likely that the cookie message store is used
> along with CSRF protection or contrib.messages, in which case Vary:
> Cookie will be set on most responses anyway, rendering this issue moot.
>
> A case could be made that the correct fix here is at an even deeper
> level; that any access of request.cookies should automatically trigger
> Vary: Cookie on the response. This follows the same logic as the current
> behavior of SessionMiddleware to set Vary: Cookie on any response where
> the session is accessed, but pushes that logic down to the common cookie
> layer where it really belongs, rather than duplicating it in the cookie
> message storage. If you are accessing cookies at all on the server side,
> presumably that means you are making some decision based on the cookie
> that might affect the response in some way, and if so Vary: Cookie must
> be set or the response might be cached incorrectly.
>
> If we don't make the fix at the request.cookies layer, we are saying that
> it is the responsibility of the developer to ensure that if they use
> cookies, they set Vary: Cookie, in which case we ought to make that clear
> in the docs. Given that it's very difficult to construct a scenario in
> which it is correct to access cookies but not set Vary: Cookie, I don't
> see much reason to place this responsibility on the developer.
>
> For this reason, I'm setting the component for this bug to "core" rather
> than "contrib.messages", even though the latter is the only place I know
> of where Django itself triggers the bug by making use of cookies without
> setting Vary: Cookie.
>
> (Thanks to Florian for presenting the hypothetical case that exposed this
> bug.)
New description:
The cookie storage backend for contrib.messages does not set Vary: Cookie
on the response, which means that (in the absence of CSRF protection or
sessions or other bits of Django that are likely to set Vary: Cookie) it
is possible for users behind a cache to miss messages intended for them,
or even for a cache to store a page with a message intended for a single
user on it and then serve that page to other users.
In practice, it is quite likely that the cookie message store is used
along with CSRF protection or contrib.session, in which case Vary: Cookie
will be set on most responses anyway, rendering this issue moot.
A case could be made that the correct fix here is at an even deeper level;
that any access of request.cookies should automatically trigger Vary:
Cookie on the response. This follows the same logic as the current
behavior of SessionMiddleware to set Vary: Cookie on any response where
the session is accessed, but pushes that logic down to the common cookie
layer where it really belongs, rather than duplicating it in the cookie
message storage. If you are accessing cookies at all on the server side,
presumably that means you are making some decision based on the cookie
that might affect the response in some way, and if so Vary: Cookie must be
set or the response might be cached incorrectly.
If we don't make the fix at the request.cookies layer, we are saying that
it is the responsibility of the developer to ensure that if they use
cookies, they set Vary: Cookie, in which case we ought to make that clear
in the docs. Given that it's very difficult to construct a scenario in
which it is correct to access cookies but not set Vary: Cookie, I don't
see much reason to place this responsibility on the developer.
For this reason, I'm setting the component for this bug to "core" rather
than "contrib.messages", even though the latter is the only place I know
of where Django itself triggers the bug by making use of cookies without
setting Vary: Cookie.
(Thanks to Florian for presenting the hypothetical case that exposed this
bug.)
--
--
Ticket URL: <https://code.djangoproject.com/ticket/19649#comment:1>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
