WordPress 4.0 decides whether the URL is http or httpS based on site environent

[cooperman]

On upgrading an installation of WordPress to version 4.0 from 3.8 we found the site in the state of an endless redirect.

After about a day and a half of trying to find the cause we saw that what appeared to be happening was that the site believed, rightly, that it was in a non-ssl environment but it then chose to act upon it and redirected traffic to ​http://site.name (non SSL domain). The setup of our hosting is that we have:

• https to the load balancer/accelerator on port 443
• http from the load balancer/accelerator to the port 81 on the web server

We had an htaccess rule in place at that location to go back to httpS://site.name which then sent traffic back again and so the cycle continued. When we removed the ​http:// to ​https:// rule, the site loaded, instead of following an infinite loop, but all of the resources (stylesheets, JavaScript, etc.) were using ​http:// so didn't load. This was despite the "siteurl" and "home" fields in the options table being set to https. We found ourselves having to hack the core code initially, on functions such as site_url, get_bloginfo(), etc. but it got to a point where it wasn't a sustainable solution.

It seems as though WordPress now makes that decision of whether to use ​http:// or ​https:// based on the server that it's sat upon instead of leaving it up to the settings in the site and what's written into the required fields in the database / settings page as versions 3.9 and earlier did.

I don't know if this is by design or not but we've had to put some serious security holes in our setup just to get the site running once again, following a day and a half of downtime. It's certainly not a feature that I've seen documented anywhere.

We're not the only users in this position (please see the thread at ​https://wordpress.org/support/topic/wordpress-40-in-a-ssl-loop?replies=6#post-6026064), and while perhaps unusual our hosting setup is hardly unique.

[DannyMe]

Dear cooperman,

Thank you very much for filing this bug report. I would like to state that we are experiencing the same bug, in different hosting environments, based on using Cloudflare's Flexible SSL-solution, which makes it possible to have a https-connection to the end user, but a http-connection to your own hosting environment:

Outside world/visitor --> https --> Cloudflare --> http --> Wordpress-installation.

As Wordpress 4.0 identifies the connection as 'http', it tries to redirect to the https-url of the installation, while the visitor is already visiting through the https-address, which results in an endless and until now non-fixable loop.

Wordpress 4.0 contains changes on how the software handles ssl-connections, although I was not able to reproduce exactly what changed. See also #27954, #28521, #28674. We urgently need a fix for this bug too for our installations, as buying SSL certificates for 20 websites is not an option and in our case not necessary.

[jeremyfelt]

Hi @cooperman, thanks for the report.

This sounds related to [28674], which forces FORCE_SSL_ADMIN to true if the site URL scheme is HTTPS, and [28610], which will redirect canonical URLs on the front end if the home URL scheme is HTTPS.

If you set FORCE_SSL_ADMIN to false in wp-config, the admin will be accessible at HTTP, even with an HTTPS site URL. Setting the home URL to HTTP will remove the canonical redirects.

[DannyMe]

Dear @jeremyfelt,

Thanks for getting back to us. Setting the home URL to HTTP does not solve the problem: in my case, I want the website to be reachable through the HTTPS-service of Cloudflare. I never had problems with this setup until the update of Wordpress 4.0 and there are much more people having this problem. Could you please help us finding a solution for this or fixing this, i would like to call it a, bug in the Wordpress software? I don't think it is desirable that a piece of software like Wordpress decides whether to redirect a user to a different URL: I think that's something that can and should be done through .htaccess.

Thanks a lot!

D.

[johnbillion]

This is indeed a result of [28610]. Altering FORCE_SSL_ADMIN won't affect this behaviour.

I'm inclined to say that this is a server configuration issue. Your load balancer should be letting your web server know that this is an HTTPS request.

If your load balancer is running Nginx then this is achieved with the HTTPS parameter of the fastcgi_param directive. With CloudFlare, I'm not sure which setting needs configuring but it should be straight forward.

The question is, is this a common enough misconfiguration to warrant reverting [28610]?

[cooperman]

Apologies for the delay; we've set up a test environment on the same hosting setup for our site so that we can make changes without risking the live site. I can confirm that FORCE_SSL_ADMIN didn't affect this behaviour. We did try this last week but we were throwing lots of things at it at that point and so I didn’t want to respond until we’d been a bit more scientific over the test.

We're now going to look at implementing the server configuration changes mentioned above.

@johnbillion - is this a hosting misconfiguration? We've got this setup by design. Is the question now "is WordPress only going to support certain hosting configurations from now on?" Other users appear to be hacking (or being advised to hack) the core WordPress files to resolve this - ​https://www.rgbartlett.co.uk/wordpress-4-https-and-tsohost-it-all-works/

[johnbillion]

Replying to cooperman:

@johnbillion - is this a hosting misconfiguration?

Yes, it is. You have a reverse proxy which is not telling your web server that the incoming request is an HTTPS request.

The question is, if this is a common misconfiguration then is it worth reverting [28610]? Moving this to 4.0.1 for consideration.

[DannyMe]

Replying to johnbillion:

The question is, if this is a common misconfiguration then is it worth reverting [28610]? Moving this to 4.0.1 for consideration.

Thanks for considering reverting this, John. I really appreciate all the effort you put into this matter. One thing I would like to put into consideration is that it might be a good idea to make this new behavior of Wordpress configurable, just like FORCE_SSL_ADMIN?

Cloudflare serves 1M+ websites. They confirmed the behavior of their service as I am experiencing it. I would say this is quite a common misconfiguration with so much websites potentially affected :)

[leetramp]

I'm new to this "ticket" side of the forum, but wanted to report that I think I'm still having the same problem. I have tried logging in to my site using ​https:// as well as ​http://, and both give me the instant timeout (I log in, and by the time the password is accepted, I'm booted back to the login page).

The site is running fine for "the public," the only problem is when we try to log in (a couple of us in different locations have tried with the same result).

We are using Awardspace for hosting, and we have an SSL certificate with them.

Thanks to everyone for all their work on this. This is the first Wordpress bug that I have not been able to find a fix for.

[johnbillion]

CloudFlare have announced ​SSL for everyone which, by default, uses Flexible SSL. Anyone who decides to use SSL for their CloudFlare proxied WordPress 4.0 site will see this infinite redirect if they change their site URL to the https version.

To that end, I'll revert [28610] for 4.0.1. I suspect we may have to live with it.

This plugin provides a simple fix in the interim: ​https://wordpress.org/plugins/cloudflare-flexible-ssl/

[chriscct7]

Before [28610] is reverted, I wanted to point out that there's a patch that could possibly solve this problem. It's this really old ticket I was looking at yesterday: #6778. Something like that, where WordPress tests to see if it will cause an infinite loop could solve the problem. Obviously the patch will probably need to be refreshed, as its from 5 years ago, but the concept is still valid.

[johnbillion]

The problem with the idea proposed on #6778 is that the redirect issued by WordPress in this case is perfectly valid (from http://example.com to https://example.com). The problem arises when CloudFlare receives the redirect, and then changes the scheme to http before acting upon it. This is what causes the infinite redirect.

[chriscct7]

It's my understanding that the patch on that ticket, and I could be completely wrong, tests a given URL to see if it will infinite redirect. Is that not the case?

[jhirschi]

Wordpress 4.0 put my site into redirect loops as well. I have https coded in the Wordpress and Site URLs to force the site as a whole to use https, with a redirect of specific pages from https to http in .htaccess. Worked fine in WP 3.9.2.

[digitaltoast]

Thanks @cooperman for reporting this, and thanks johnbillion for agreeing to rever [28610] and saving use Cloudflare users headaches in the future!

[johnbillion]

Fixed for trunk in [30090].

[johnbillion]

Re-opening for 4.0.1.

[chriscct7]

@johnbillion Did you mean 4.1?

[jeremyfelt]

#30241 was marked as a duplicate.

[guaka]

I'm trying a workaround now: I set WordPress Address (URL) to http and Site Address (URL) to https at wp-admin/options-general.php

[johnbillion]

Replying to chriscct7:

@johnbillion Did you mean 4.1?

Nope, this is fixed in trunk (for 4.1), and is pending a merge into the 4.0.1 branch. We use the fixed-major label for this situation.

[nacin]

[30253] and [30090]