Make WordPress Core

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's profile 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.:

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)

#1 @brevilo
4 months ago

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.

Last edited 4 months ago by brevilo (previous) (diff)

#2 @brevilo
4 months ago

  • Component changed from General to Security

#3 @hellofromTonya
2 months ago

  • Version changed from 6.6 to 2.0.5

Changing the Version from 6.6 to 2.0.5.

#4 @johnbillion
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 @brevilo
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

Note: See TracTickets for help on using tickets.