#27373 closed defect (bug) (fixed)
"Cookies are blocked" error is misleading
Reported by: | SergeyBiryukov | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | 3.7 |
Component: | Login and Registration | Keywords: | has-patch commit |
Focuses: | Cc: |
Description (last modified by )
A lot of users reported "Cookies are blocked or not supported by your browser" error on login page after the upgrade to 3.7. Most of the time it has nothing to do with their browser.
Before 3.7, the presence of the test cookie was only checked in case of an invalid username or password.
Since [25045], we always check the test cookie before calling wp_signon()
. This made the issue much more prominent. Some articles even suggest hacking core as a workaround, which induced me to investigate it.
Here are some scenarios to reproduce it:
- Some proxy/caching servers (e.g. Varnish) are configured to not allow setting cookies on GET requests. On a second attempt (after a POST request has been made), user is able to log in.
- One of the active plugins (or the theme's
functions.php
file) produces unexpected output, causing a "headers already sent" warning and consequently preventing WordPress from setting the test cookie. - UTF-8 byte order mark in
wp-config.php
(or theme'sfunctions.php
file) has the same effect as above. - Invalid COOKIE_DOMAIN value in
wp-config.php
. According to the original cookie specification, the domain value, if specified, must have at least two dots, so 'localhost' is invalid. - CloudFlare caching rules prevent the test cookie from being set.
Attachments (2)
Change History (8)
#3
@
11 years ago
- Keywords commit added
27373.diff modifies the strings a bit. End result:
- ERROR: Cookies are blocked due to unexpected output. For help, please see <a href="%1$s">this documentation</a> or try the <a href="%2$s">support forums</a>.
- ERROR: Cookies are blocked or not supported by your browser. You must <a href="%s">enable cookies</a> to use WordPress.
The second one is actually not new text, but rather than linking to google.com/cookies.html, we should link to http://codex.wordpress.org/Cookies. This is a page I just created. It needs work, but it's a start.
I've otherwise tested the patch and it is ready to go.
#4
@
11 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 27859:
#5
@
10 years ago
Looks like Sergey's patch made it into 4.0. But it hasn't solved the problem for me.
I have a multisite with a few sites set up in version 4.0.
I just added a new domain so there are no cookies in my browsers for that domain, and I am using the default theme (2014).
When attempting to login, I get the "Cookies are blocked" error.
I know the credentials are good, and I have tried with with both firefox and internet explorer on separate computers, each browser with extensions disabled. I followed the instructions on the firefox page to make sure cookies are enabled.
I disabled all the plugins on my WP multisite (network deactivate) but this has not helped. I've spent a full day on this but I have not been able to solve the problem.
I am accessing it from a home network with no special proxies to go through, and I can confirm that there are plenty of other cookies in my firefox browser, some of which are for the other domains in my multisite installation for which I remain successfully logged in.
I have put this up for discussion in the forums, but no one seems to have any ideas.
https://wordpress.org/support/topic/login-cookie-error-multisite
Should I open a new bug?
Instead of always checking the test cookie (which may or may not be set), I think we should check if we actually failed to set
LOGGED_IN_COOKIE
first, and add a distinct message for the "headers already sent" case.This would fix scenarios 1 and 5 and make troubleshooting much easier for the other three (we should ideally add some validation for
COOKIE_DOMAIN
in a new ticket).See 27373.patch.