Opened 4 months ago
Last modified 11 days ago
#61711 new defect (bug)
Password-protected pages lacking appropriate 'Cache-Control' request header
Reported by: | brevilo | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 2.0.5 |
Component: | Security | Keywords: | needs-patch good-first-bug |
Focuses: | Cc: |
Description
Over the years there have been recurring reports of users having issues with password-protected pages which simply redirected to the password prompt again, instead of the actually protected page (after successful login), e.g.:
- #3445
- #4030
- Four-year-long discussion (now closed)
The tickets got closed with "worksforme" and the discussions kept looking at the WP config, plugins or client-side issues, but so far without reliable solutions. Since I myself ran into the same problem as so many others before, I now analyzed it and found the (well, at least a) culprit.
I narrowed it down to be a caching problem at my hosting provider, seemingly using Nginx as a caching reverse-proxy! This could also explain the "worksforme" closures above: if your provider doesn't use such caching (or a CDN for that matter), you won't reproduce it.
In my case the response headers (after the successful) redirect contained:
X-Cache-Status: HIT
(see this FAQ)
As a workround I now send the appropriate header tailored for this situation, as part of my theme:
<?php header('Cache-Control: private');
For me, and probably a lot of others (reverse-proxy caching or CDNs are widely used) the solution would be to do this for all password-protected pages. Remember that header()
must be called before any actual output is sent.
Thanks
Change History (5)
#4
@
2 weeks ago
- Keywords needs-patch good-first-bug added
- Milestone changed from Awaiting Review to Future Release
Thanks for the report @brevilo! Would you be willing to work on a PR or patch to get this fixed?
#5
@
11 days ago
Willing, sure, but I've never seen this particular codebase before and I don't know your dev process. Given that the fix should be trivial (a one-liner in the right place), I'm sure an existing dev can do a much better and faster job than me. I don't care about authorship credit, so please feel free to just fix it :)
Cheers
Here's one of many examples where troubled users switched their provider and the problem was gone. To me this also hints at a reverse-proxy setup. This fix could really positively affect as lot of installations, I reckon.