As of WP 3.2 and WordPress HTTPS 1.9.0, it looks like the plugin is now logging in on one-or-the-other (HTTP or HTTPS). Furthermore, it’s completely taking over the login function instead of hooking into it.
Hey Scott,
This has been fixed since 1.9.1. However, the plugin does not log the user into both HTTP and HTTPS. Perhaps I can add that as an option into the plugin at a later date.
I did take your code and incorporate the idea of not using the pluggable functions, but this did not make it into 1.9.2, but will be in the next version. Thank you. 🙂
Thanks,
Mike
@mvied – Sounds great, please make the login on both HTTP / HTTPS standard if possible, otherwise set it up as an option. Maybe best of both worlds, have option set to on by default?
Perhaps. The only thing that stinks about it is with people using Shared SSL, the cookies can only be set for the current domain. So, I can’t set their HTTP cookies. I may try to devise a method around that using an AJAX call to set the HTTP cookies, but obviously there would be security concerns.
Setting the option on by default is reasonable, so long as they aren’t using force_ssl_admin in WordPress using Private SSL, or the Force Shared SSL Admin option in WordPress HTTPS.
I’d like to get the Shared SSL HTTP cookies sorted out before I put that feature into a release. Otherwise it just kind of feels like half of a feature. 🙂
I’m using the plugin on commentarymagazine.com (not upgrading until the feature is added, so just running my patched copy from 1.8.x)
On that site, when a user logs in, part of the site is in HTTPS and part of it is in HTTP. They log in via HTTPS, and my code (as seen in the original post above) sets the cookies for HTTP and HTTPS accordingly. Whatever end-game solution you can find that can keep that working for us in a future release, I’ll be happy 😉
One big thing is that the AUTH_COOKIE used for cookie name and corresponding secure auth cookie uses a MD5 off of the http / https version of the page, when the real WP site url is one or the other
Hey Scott,
I was actually messing around with your edited 1.8.5, but I can’t seem to get it to keep me logged into the admin panel over HTTP and HTTPS at the same time. I’m having the same problem with my development version, so I wanted to see if your version actually worked, but I get the same results.
Thanks,
Mike
The code was working for us at commentarymagazine.com
When someone logs in, it logs them into both the http/https versions of the site. Though I think there might be some better ways to accomplish it, mine was put together when we had issues and we needed a solution fast.
Hey Scott,
What version of WordPress was that site using? Your patched 1.8.5 version does not work on my development site which is 3.2. It seems to fail when WP validates the cookie and then proceeds to log you out entirely. Which is the same thing that happens even when the plugin is disabled.
Also, when you look at the cookies when logged into HTTP or HTTPS, the hashes are the same, only the first part of the cookie name is different. So, I’m not sure if changing the hash around is necessary.
After my experiences with trying to get this to work, I don’t really see the benefit. WordPress sets the logged_in cookie for both HTTP and HTTPS by default, which is enough to get the admin bar and such to appear on the site. Why do you need to log into both?
The only way I see this working is to alter the cookie validation and such, which could be quite time consuming.
Thanks,
Mike
Sorry, I’ve been moving into our new house over the past 2 weeks so I haven’t had a chance to reply.
I’m going to go back over the functionality specifically and test on a sandbox site, but what this site is doing special is that wp-config.php sets the URLs depending on HTTP / HTTPS. Because of this, the Cookie doesn’t match (since the cookie is set on HTTP for HTTP/HTTPS using the hashes created from the current URL defined in WP which is still HTTP at that point).
if (!empty($_SERVER['HTTPS']) && 'off' != $_SERVER['HTTPS']) {
define('WP_PLUGIN_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content/plugins');
define('WP_CONTENT_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content');
define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']);
define('WP_URL', 'https://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST']);
}
else {
define('WP_PLUGIN_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content/plugins');
define('WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content');
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_URL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);
}
Hey Scott,
If that’s the reason that that plugin works (which I’m pretty sure it is) there is no way to reproduce that functionality in a plugin. But, it gives a little insight into why it was working on that site. Let me know how it works out.
Thanks,
Mike
Thought I’d post some code that I use to log users into both http and https at the same time. It’s pared down from a larger bit of code, and will eventually be added to my “improved user experience” plugin:
[Code moderated as per the Forum Rules. Please use the pastebin]
Code: http://pastebin.com/wHZY4rdY
I guess I should have explained it. It’s pretty simple really. When wp_set_auth_cookie() is called I hook into one of it’s hooks (set_auth_cookie). If the cookie being created is http I call it again to create the https one (and vice versa). The $_second_auth variable is used to make sure we don’t end up in an infinite loop since we’re calling a function from a hook that it triggers.
The rest of what’s here is optional and just makes the class a singleton. It’s really not needed in this particular usecase, but if you accidentally get multiple instances of this class you’ll end up setting the cookies over and over.
