https / preview bug with 2.0 (not in 1.8.1)

Hello vnworks!

We’re working on fixing this right now.

Thanks you the well written report!

I’m having the same problem, just to chime in.

This issue is caused by a failure in some SSL plugins to properly protect all authenticated pages with SSL. Errors in these plugins may leave your site(s) vulnerable to attacks by allowing authentication over non-SSL connections.

To protect your site credentials, Duo WordPress 2.x will log a user out if the base URL in the Duo cookie is different from the base URL of a page which requests authentication. Among other things, this prevents attackers from potentially stealing your credentials via a MITM attack (which is what SSL would be doing if it were actually protecting the necessary page(s)).

That is to say, when using SSL on your login page the base url picked up by the Duo WordPress cookie is https://example.com. Since https://example.com does NOT match http://example.com, you are logged out when a page begining with https://example.com requests unsecured authentication (preview pages, in this case).

Rolling back to 1.8.1 removes the issue because Duo WordPress 1.x does not perform this URL validation.

The quick (and most secure) resolution is to enable SSL site-wide by changing the base URL from HTTP to HTTPS in your general WordPress settings and removing any SSL plugin.

If you do not want site-wide SSL, the best resolution is to work with the author(s) of your SSL plugin to make sure that ALL authenticated pages are served over HTTPS. (We may also work with the authors of these types of plugins as we have the resources to do so.)

If you have any questions, comments, or support requests please direct them to [email protected] for further assistance.

Thanks!

Can’t you just add a mode to turn that off (optionally with a big red warning)? The problem in my case is the front-end is crazy cached using a CDN which doesn’t support CNAMEs with SSLs. Technically I suppose this is an issue with W3 Total Cache for not being able to specify HTTP and HTTPS URLs for the CDN.

That said, having Duo in place is surely better than the converse so I’d rather risk the HTTP vs HTTPS issue.

Thanks for the suggestion, m00dawg.

We had thought about adding an option like this, but weren’t sure if it was something users wanted. Now that you’ve requested it, I’ll file a feature request and we’ll see where it goes.

CDN caching may be a factor. But I’m not inclined to think that it is here. I may not have been clear enough in my last post. The validation isn’t simply HTTP vs HTTPS. Rather the validation checks that the base login URL (from http(s):// all the way up to the TLD) matches on any pages requesting authentication. Additionally, caching on your normal front-end pages shouldn’t be problematic, as they do not require authentication checking with each page load the same way privileged pages (/wp-admin/, previews, etc.) do.

By the way, we’re actively looking for beta testers to work with us on testing new versions of Duo WordPress. During beta installation/testing you’ll be assisted live, over the phone, by a Duo engineer. If this sounds like something you’d like to help with, email [email protected] and let us know!

Thanks!

Ah but they actually can in a way. The problem is our site doesn’t come up correctly using HTTPS to view any of the non-admin pages. So when we go to Preview, things end up being a bit of a mess.

I think you’re right in that this is likely caused by a plugin (W3 Total Cache I’d bet). Trouble is, we can’t just up and turn that off as it makes a huge difference in the amount of traffic that ends up hitting our website and, thus, to performance.

Where it gets really weird is with the top WordPress admin bar. That will get served on non HTTP. If I recall, the problem is noticed when you try to use that bar in that configuration.

Generally, I agree with you as far as HTTPS goes though we’re not quite ready to do HTTPS-on-everything just yet even though it’s an epically good idea.