[wp-trac] [WordPress Trac] #61711: Password-protected pages lacking appropriate 'Cache-Control' request header

[WordPress Trac]

#61711: Password-protected pages lacking appropriate 'Cache-Control' request header
-------------------------------------------------+-------------------------
 Reporter:  brevilo                              |       Owner:
                                                 |  johnbillion
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  6.8
Component:  Posts, Post Types                    |     Version:  2.0.5
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-testing-info has-      |     Focuses:
  unit-tests 2nd-opinion                         |
-------------------------------------------------+-------------------------
Changes (by johnbillion):

 * keywords:  has-patch has-testing-info has-unit-tests => has-patch has-
     testing-info has-unit-tests 2nd-opinion


Comment:

 Given the reverse proxy configuration from the ticket description, I'm
 concerned that the proposed change will have the side effect of allowing
 the password protected page content to be written to the page cache after
 the password has been entered by a visitor.

 Reasoning: If the request after the redirect can return a cache read `HIT`
 despite the presence of a `wp-postpass_COOKIEHASH` cookie (causing the bug
 reported in this ticket), then it's reasonable to assume it can also write
 to the cache with the current page contents when there isn't a hit. This
 enables a form of cache poisoning that facilitates exposing the password
 protected content to visitors who have not entered the password but who
 are served the cached response that was written after a visitor entered
 the correct post password.

 I think the complete solution here is to always send no-cache headers for
 password protected posts, regardless of whether the visitor has entered a
 password. This prevents caching of either the password input form or the
 password protected content. I think that is what @brevilo's code in their
 theme is doing, but the patch on this ticket took a different approach.

 @haozi @ironprogrammer @brevilo What do you think?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61711#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform