Opened 5 years ago
Last modified 5 years ago
#49136 new defect (bug)
White screen in password protected posts, referrer policy
Reported by: | derfuchs98 | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.3.2 |
Component: | Posts, Post Types | Keywords: | |
Focuses: | privacy | Cc: |
Description
Background
Under some circumstances WP is displaying a white screen refering to URL ..../wp-login.php?action=postpass after entering either correct or incorrect password into password protected posts. It turns out this behaviour occurs reproducably in case WP site is set to no-referrer policy e.g. by Nginx configuration. This behaviour was observed since about July last year.
Steps to reproduce
- Force no-referrer policy in Nginx .conf file
add_header Referrer-Policy no-referrer;
service nginx restart
- Protect any post by password
- Verify no-referrer policy in e.g. Chrome F12->network
- Enter password into your password protected post
- /wp-login.php?action=postpass white screen pops up, no error message, no debugg hints.
These steps reproduce in any WP configuration (under ubuntu server 18.04 LTS, LEMP stack) with or without themes/plugins. Exception: Safari and Edge (as of August last year) do not show white screenn. Reason: These browsers do not support referrer policy.
Work around
Set referrer policy to any other policy than no-referrer. In my case strict-origin-when-cross-origin did the job.
Suggestion
This issue might not be too common but it might become more relevant due to GDPR in Europe.
It seems that wp-login.php requires a reference to the calling URL to be able to redirect to that URL after verifying the password. In case of no-referrer policy this reference is not disclosed, hence wp-login.php cannot return to its caller.
If that is the case in order to ensure stable operation of password protected posts WP must not allow no-referrer policy but should force any other secure policy.
This ticket was discussed during today's accessibility bug-scrub. @derfuchs98 thanks for your report! Not sure this issue relates to web content accessibility (as in WCAG and the like). Adjusting the ticket properties accordingly.