HTTP and HTTPS differences for function is_user_logged_in() in WordPress 4.0

I’m having this problem too. Was this quirk introduced in 4.0?
Did you find a workaround, David?

It’s a real pain as it means my header shows the login link even when they’re logged in, instead of their name, profile and logout links.

I also notice get_currentuserinfo(); is empty when over http, and populated when https.

This isn’t a quirk, it’s a security feature.

Yes, if a user signs in via https, then their cookie will be a secure one, marked for https only usage. Sending it over an http link would be a problem because http is not secure. The cookie could be sniffed or stolen and used to authenticate as that user.

The bottom line is that you should not mix https and http in the first place. If a user is signed in via https, then everything should be https from then on. The mixing of the two leads to security issues.

It is a change that happened in 4.0, but it only affected my development environment. I have a plugin that just adds a filter to prevent the secure_logged_in_cookie from being used, defaulting back to the non-secure one.

Again, the issue only existed on my development environment, so I wasn’t concerned about security.

function disable_secure_logged_in_cookie() {
	return FALSE;
}
add_filter( 'secure_logged_in_cookie', 'disable_secure_logged_in_cookie' );

The other solution you could do is create mod_rewrite rules to move all signed-in users to browse via https since the ssl overhead isn’t too bad. However, the problem is if the visitor closes their browser and comes back to your site via HTTP, then they see your site as no longer “signed in.” You could then also create a separate plugin to check on initial visit to check for a secure cookie’s existence while HTTP.

The other solution you could do is create mod_rewrite rules to move all signed-in users to browse via https since the ssl overhead isn’t too bad.

It’s a commonplace myth that using SSL creates overhead. In reality, the overhead incurred by using all-SSL connections is so low as to be practically non-existent.

If you’re interested in the deep technical detail, this is a good read talking about the results when Google switched GMail to be SSL-by-default:
https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

The take away from that article is this line: SSL/TLS is not computationally expensive any more.

My advice if you do have some SSL stuff would be to just go all-SSL, all the time, for all the things. It’s simpler in the long run, but in the short run you will have mixed-content issues to sort out, maybe some caching issues if you do any sort of caching. But honestly, trying to switch people back and forth and maintain both and have everything work is far too much hassle. Pick one, stick with it. Going full-HTTPS doesn’t have performance problems any longer.

Thanks for the info guys. Very informative.
I’m a little confused though. If I go to Amazon, Next or Play.com, for example, log in and the account page is naturally https. But If I move away to the homepage or a product page, the content is https.
So are we saying that this is a big no-no?

I think you meant to say http for that second one there.

In general, yes, it is preferred not to mix the two. But Amazon is using a lot of different cookies, all for different purposes. When I check, I see 17 cookies there on the main page alone.

In the long run, going full-SSL makes more sense. It’s easier. There’s less that can go wrong. And you don’t have to take my word for it: Google prefers SSL.

Thanks Samuel