"Cookies are blocked or not supported" since update to 3.7.1

I have been able to verify that if WordPress is running behind Varnish, then it is quite possible that non-admin/login cookies will be deleted (depending on Varnish configuration):

My website is now super-fast with Varnish

And here’s a Varnish 3.0 WordPress configuration template: wordpress.vcl

The Varnish template includes:

# Drop any cookies sent to WordPress.
if (!(req.url ~ "wp-(login|admin)")) {
    unset req.http.cookie;
}

But I’ve seen examples where this part is commented out and it’s set to delete all WordPress cookies…

I’d really like to test this, but I just don’t have the time to set up Varnish at the moment.

I’ve Varnish installed and the same info you’ve above and issue remains. I see what you are saying, but I’m not sure if it would make sense because the initial load of login doesn’t set the test cookie, but second attempt at login does and I can see cookie has been set in Firebug, so Varnish is not deleting the cookie. I’ve disabled Varnish completely on one domain so I can rule it out.

OK, curiosity got the best of me and I installed Varnish.

Actually, it’s conf.d/fetch/wordpress.vcl

By doing this:

#if (!(req.url ~ "wp-(login|admin)")) {
    unset beresp.http.set-cookie;
#}

I can stop the testcookie from being set and I get the “Cookies are blocked or not supported” error. However, that gives me the error on WordPress, at least back to 3.6.1, and if I uncomment the if statement, it works on 3.7.1. So yes, Varnish can cause the issue, but it doesn’t seem to be 3.7.1 specific. (but once again, it could depends
on configuration)

So I’m bowing out this thread…I can duplicate it, but I’m not sure my results mean much.

It would be this:

sub vcl_fetch {
    # Drop any cookies WordPress (except for wp-login/wp-admin) tries to send back to the client.
    if (!(req.url ~ "wp-(login|admin)")) {
        unset beresp.http.set-cookie;
    }
}

But that configuration works, and deleting out the if will make it fail for all recent versions of WordPress, not just 3.7.1.

@scriptrunner what still bothers me is that I have two completely independent installs of WordPress 3.7.1 (running with the same webhoster), both have simultaneously developed the same issues. One is the one we experimented with, the other has not been touched, not re-uploaded or whatever and was upgraded every time a new version of WordPress became available. Their behaviour is identical.

I downloaded fresh archive versions of 3.5, 3.6, 3.6.1, 3.7, and 3.7.1. What I did notice is that wp-login.php did not change between 3.7 and 3.7.1. 3.5-3.6.1, wp-login.php sets the test cookies in the same way as it does in 3.7+, but the code dealing with logic for a missing test cookie is somewhat different between pre-3.7 and 3.7+.

I’ve been guessing too much, but it seems that nothing in 3.7/3.7.1 has changed in regard to setting of the test cookie when first hitting wp-login.php. You might try removing:

<input type="hidden" name="testcookie" value="1" />

as that should disable the test cookie check on form submission.

As I said, for now I’m going to bow out of any more troubleshooting suggestions, at least until I discover something substantial. It seems to be an environment issue of some sort. I run a dozen or so sites using three different hosting companies and have yet to have any problem, which is the opposite of your situation.

I’m back in work mode, so I’ll have lest time to devote this issue. If I discovering something tangible, I’ll let you know.

@scriptrunner thank you, I understand. Sooner or later something will come up and I’ll be able to use the admin screen again ….
By the way, removing the line you suggested removes the error message. But instead of opening the admin screen there is only a white screen, and that’s it.
One final question: when inspecting headers of the other site, the engineer got this returned:

Pragma: no-cache
2. Proxy-Connection: Keep-Alive
3. Server: Apache/2.0.52 (Red Hat) FrontPage/5.0.2.2635
4. Transfer-Encoding: chunked
5. Via: 1.1 W0211, 1.1 W020

He was wondering whether that last “Via” line is version info of Varnish?

@willem.deboer – When I get a chance, I’ll double check that testcookie hidden variable. I saw a post on BuddyPress where that was removed so it would work with WordPress. As far as I can tell, all it does is remove the check if test cookie exists, and things should work as normal. Does WP_DEBUG show anything? Otherwise, it would be nice to know what’s showing up in the server error log.

As far as the headers, “Via” is used in both http request and response headers to show which proxy servers request/response went through. Whether it’s Varnish, I don’t know. I could see what I get back on my local test install, but it’ll have to be a bit later today.

I’m still able to login by after removing:

<input type="hidden" name="testcookie" value="1" />

but then again, I’m not having any trouble with it either. I would be very curious what’s in the server error log if you can get access to it or the engineer can get you a copy.

Here’s what I get as far as varnish goes (on the response):

X-Varnish: 827414583 827414582
Age: 83
Via: 1.1 varnish

I’ve tried just making sure cookies work on server, thought maybe it was a PHP update that messed it up. Tried using this https://code.google.com/p/cookiecheck/ and it always says Cookies Disabled. So now I do not think this is a wordpress issue and could be a PHP issue from a version update. (Coookies work fine when checking with javascript, just not with php.)

Interesting. I just deleted 3.7.1 except for wp-content, .htacess and wp-config.php. Then re-uploaded version 3.7. Guess what? Same error.
I’m just not quite sure yet what that tells me.

I think the consensus of opinion is that this is a server issue.

Yes, it must be. What do the servers of people who experience this issue have in common? Version of DBMS, PhP, what else is there.

Could also be varnish in my case. Currently looking over the rules to unset cookies depending on where I am on the site…