User loses logged_in cookie but not other auth cookies

[mintindeed]

We have a user on Chrome for Mac who lost his wordpress_logged_in_* cookie somehow, but kept the wordpress_* cookies set to the /wp-admin and /wp-content/plugins paths. He was able to perform admin actions such as editing posts, but was unable to preview posts, and was not seeing content that’s available to logged in users.

We have heard reports from another user using IE8 on Windows 7 that sound like this may have happened to her as well. Two different browsers and OSes, so it doesn't seem browser or OS-specific.

As of yet, we are unable to reproduce this issue on demand. Because we can't reproduce it on demand, we can't determine whether it's WP core, a plugin, or some external factor that is causing the problem. However, we have validated that if you lose the wordpress_logged_in_* cookie on a stock install of WordPress, this behaviour does exhibit itself -- you stay logged in to the admin, but you're not logged in on the frontend.

This sounds like a support issue, and we have worked with WP support to resolve it, but haven't been able to rule out that WP core is the cause. We couldn’t find anything in WP core that looked like it could remove the logged_in cookie but not the others, but there are people here who are more familiar with WP core than us. :)

Obviously this is an edge case, and it's solvable by logging out and logging back in -- but that assumes you know that you're having this problem, and that's not obvious to a regular user.

I am trying to determine if a bug exists and whether it's the cause of this and other "clear your cache and cookies and it will work" issues.

Additionally, it seems like a bit of overkill that WordPress would set 3 authentication cookies. Perhaps this is because of SSL logins to the admin, but couldn't that be solved by setting a single non-secure cookie to /, and then if SSL is enabled setting a second secure cookie?

[nacin]

One cookie -- for wp-content/plugins -- is for compatibility, see [8209].

Separating the other two are important. The admin cookie would normally handle the entire site, but for security purposes this privileged cookie is restricted to /wp-admin/. Thus the generic logged-in unprivileged cookie handles the frontend. It actually doesn't have to do with SSL, which introduces additional complexity all on tis own.

we have worked with WP support to resolve it

Link? Or are you referring to WordPress.com, the separate hosted service?

With regards to the bug, not a clue what would cause this. We set and destruct these cookies all at the same time. That said, we could check for the existence of wordpress_logged_in_* on the backend, and set it if for some reason it is missing.

[nacin]

That said, we could check for the existence of wordpress_logged_in_* on the backend, and set it if for some reason it is missing.

Couldn't do it the other way around of course, as that defeats the purpose of the security measures.

[mintindeed]

Replying to nacin:

One cookie -- for wp-content/plugins -- is for compatibility, see [8209].

Separating the other two are important. The admin cookie would normally handle the entire site, but for security purposes this privileged cookie is restricted to /wp-admin/. Thus the generic logged-in unprivileged cookie handles the frontend. It actually doesn't have to do with SSL, which introduces additional complexity all on tis own.

I see, that makes more sense.

we have worked with WP support to resolve it

Link? Or are you referring to WordPress.com, the separate hosted service?

Whoops, I meant WP VIP support. batmoo there suggested I check in here.

With regards to the bug, not a clue what would cause this. We set and destruct these cookies all at the same time. That said, we could check for the existence of wordpress_logged_in_* on the backend, and set it if for some reason it is missing.
Couldn't do it the other way around of course, as that defeats the purpose of the security measures.

I was thinking along the same lines, but it's worrying to just re-create it without actually understanding why it went missing.

Good to know that wp_clear_auth_cookie() and wp_set_auth_cookie() are the only places these cookies are written or removed. That makes it unlikely that anything in core is causing this issue.

We have put in some cookie logging on one of our sites, and will be rolling it out to the rest soon. Hopefully with ~30+ editors over a few different domains, if this is a recurring problem we'll see it happen again and be able to learn more.

Thanks for weighing in.

[mintindeed]

We've seen the issue a couple of times since this ticket was created, but our logs don't show a smoking gun -- the logged in cookie is there, and the next page request it's not (but the other auth cookies are still present).

[edwardw]

Is this still an issue with the latest WordPress version? Looks more like a support issue than a defect in the core code.

[SergeyBiryukov]

Feel free to reopen with more information if this turns out to be some bug in the core.