Use cache-control headers on pages requiring authentication
See original GitHub issueIssue Summary
When a Page is password protected, its publicly-viewable version displays a password form at the Page’s URL. If caching is used, this means that the form itself can get cached, preventing the user from progressing to the Page itself - the cached password form can keep getting returned.
I and @vsalvino had this issue using wagtail-cache, which he provided a solution for. But he suggested that if Wagtail itself issued cache-control: private
headers when the page required authentication, that would probably make more sense.
Steps to Reproduce
- Install wagtail-cache (or maybe use some other caching solution)
- Create a Page, set it to Live, and protect it with a Password
- Visit the Page’s URL and enter the correct password
- Instead of getting the Page itself, the form will be returned.
Technical details
- Python version: 3.6
- Django version: 2.1
- Wagtail version: 2.4
- Browser version: macOS Safari 12
Looks like there was a similar proposal in 2015, closed due to lack of interest. @loicteixeira in Slack suggested I open this.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:4
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Cache-Control - HTTP - MDN Web Docs
The Cache-Control HTTP header field holds directives (instructions) — in ... In general, when pages are under Basic Auth or Digest Auth, ...
Read more >Incorrect Cache-Control headers for authenticated users
Problem / Motivation When using the page cache, we will generate the following HTTP headers when we need to by-pass the cache: ...
Read more >Caching Header Best Practices - Simon Hearne
Caching headers are surprisingly complex and often misconfigured. Here we look at some key cache scenarios and recommend the ideal headers ...
Read more >Authorization check for HTTP Caches - Stack Overflow
However, you can make authenticated pages public with a Cache-Control: public header; HTTP 1.1-compliant caches will then allow them to be ...
Read more >The Clear-Site-Data Header in Spring Security - Baeldung
Learn how to use Spring Security's with ClearSiteDataHeaderWriter to add the ... For websites that require authentication, the Cache-Control ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I was thinking that the
Vary: Cookie
header that Django automatically emits wheneverrequest.session
is accessed would solve this. But this might not be the case if the cookies are being created by this view.What I think might be happening is follows:
When the first user without a cookie visits the page, Django creates session and returns response with
Set-Cookie
andVary: Cookie
headersWhen the second user without a cookie visits the page, the cache returns the first user’s response because the first user didn’t have a cookie when they made the request (and
Vary: Cookie
probably isn’t clever enough to see theSet-Cookie
in the response)If that’s the case, then adding
Cache-control: private
or justCache-control no-cache="Set-Cookie"
should solve it.The lack of
Cache-Control
headers caused us not only an availability issue (CSRF errors when attempting to log in) but also significant security issues (the password-protected content was visible without logging in due to the cache, once a different browser could log in).https://github.com/coderedcorp/wagtail-cache/issues/35 details some of our testing (the lack of a “don’t cache” Cache-Control header is a problem for core, it would seem)