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

  • David

    (@dlim_vernier)


    After upgrading to WordPress to 4.0, I find that the function is_user_logged_in does not work where the user signs in with HTTPS, but then returns to HTTP for browsing non-private areas.

    I have an apache rewrite rule that redirects some paths to https due to account-specific information, but everything else, I redirect to http for less overhead.

    On the site, there is a navigational bar that shows who the current user is at the top. After the user signs in, the navigational bar doesn’t show the user is signed in when it’s http, but it does for https. So this leads me to believe that the cookie to determine if a user is signed in checks for http vs https.

    I tried setting the AUTH_KEY and SECURE_AUTH_KEY as the same hash, as well as AUTH_SALT and SECURE_AUTH_SALT to see if that help, but I still have the same problem.

    After some digging, it seems that the cookie set after signing in HTTPS will not be available to WP in HTTP.

    I’d prefer if I didn’t have to force all users to go HTTPS if they’re signed in. I’m open to ideas.

Viewing 8 replies - 1 through 8 (of 8 total)
  • 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.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    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.

    David

    (@dlim_vernier)

    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.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    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?

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    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

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘HTTP and HTTPS differences for function is_user_logged_in() in WordPress 4.0’ is closed to new replies.