Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#27373 closed defect (bug) (fixed)

"Cookies are blocked" error is misleading

Reported by: sergeybiryukov's profile SergeyBiryukov Owned by: nacin's profile 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 SergeyBiryukov)

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:

  1. 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.
  2. 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.
  3. UTF-8 byte order mark in wp-config.php (or theme's functions.php file) has the same effect as above.
  4. 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.
  5. CloudFlare caching rules prevent the test cookie from being set.

Attachments (2)

27373.patch (1.5 KB) - added by SergeyBiryukov 10 years ago.
27373.diff (1.8 KB) - added by nacin 10 years ago.

Download all attachments as: .zip

Change History (8)

#1 @SergeyBiryukov
10 years ago

  • Keywords has-patch added

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.

#2 @SergeyBiryukov
10 years ago

  • Description modified (diff)

10 years ago

#3 @nacin
10 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, we should link to 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 @nacin
10 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 27859:

Only show test cookie warnings on submit as caching/proxies may intercept the test cookie for GET requests.

Introduce a new string for when headers are sent and link them to (new page).

props SergeyBiryukov.
fixes #27373.

#5 @tezza71
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.
Should I open a new bug?

Last edited 10 years ago by tezza71 (previous) (diff)
Note: See TracTickets for help on using tickets.