Multisite is hardcoded to redirect to http:// for invalid domains

[glen.pike.hf]

We have a multisite installation configured for sub-folders, which is served to the non-logged-in users over SSL.

Scenario is that WP is used as a help system with a number of language / feature translations for different levels of customer. The install sits on a server behind a proxy serving on SSL. Customers will have different domains depending on who they are, but their help should be served from the default site.

If we use any domain which does not match the DOMAIN_CURRENT_SITE value, the user is redirected to DOMAIN_CURRENT_SITE + PATH_CURRENT_SITE, etc.

The problem we have is that ms-settings.php is hardcoded to use "​http://" for this redirection. This breaks our site for users as we don't serve on port 80.

The request is to change ms-settings.php to check for SSL and use the correct protocol for redirection.

We've tried some different plugins to resolve this, but have not successfully managed to avoid the initial redirection.

Setup:

Configure server to use SSL only.
Install Wordpress in a subdirectory of the web server's document root.
Enable multisite and configure.
Add a second site.
Create a "dummy" domain in your hosts file to point at the server.
Visit the Wordpress install using the dummy domain on SSL

[glen.pike.hf]

has-patch needs-testing

[johnbillion]

Related: #20204

[jeremyfelt]

Relevant code in ms-settings.php

if ( $current_site && ! $current_blog ) {
	if ( $current_site->domain != $_SERVER[ 'HTTP_HOST' ] ) {
		header( 'Location: http://' . $current_site->domain . $current_site->path );
		exit;
	}

It seems the answer here isn't necessarily checking for the scheme of the request, but checking for a desired scheme assigned to the $current_site->domain the redirect will be made to. If the domain requested is invalid, there's nothing saying that the scheme is valid.

For this block of code in ms-settings.php, that would be likely be a network level setting as we're redirecting to the network's main page.

I guess one question would be whether forcing SSL in this scenario should occur in WordPress core, or in the web server configuration as an immediate redirect.

[jeremyfelt]

Thanks @glen.pike.hf for taking the time to report and submit the patch!

[glen.pike.hf]

It seems the answer here isn't necessarily checking for the scheme of the request, but checking for a desired scheme assigned to the $current_site->domain the redirect will be made to. If the domain requested is invalid, there's nothing saying that the scheme is valid.

That makes sense to me.

I guess one question would be whether forcing SSL in this scenario should occur in WordPress core, or in the web server configuration as an immediate redirect.

Our particular Wordpress setup is such that we have a WP host on port 80, but it is behind a proxy serving on SSL. The visitor sees WP on ​https:// but Wordpress' Apache config is not.

[hopetommola]

I think this may be related to the issue I'm having, so prior to submitting a new ticket, I thought I would comment. We have a subdirectory multisite installed with https set up on the server. All pages were being called through https, but the media in the pages and posts were http, thus throwing browser errors.

After scrutiny, the short story is all media is forced http, because the home and siteurl urls are somehow hardcoded to http, even though the main blog is https. And the issue can be completely and fully resolved by manually adding "the magic s" to the home and siteurl urls in the wp_X_options table related to that subsite.

[jeremyfelt]

It looks like this was fixed as a side effect of [27663] for #21143. We now use the scheme of the request to build the redirect URL.