get_home_path() fails if admin area is SSL but not the frontend

[GregLone]

Hello.

In case you use SSL for the administration area and not the frontend, get_home_path() will fail to retrieve the home path.
In this case:
home url: ​http://example.com
site url: ​https://example.com

Current version:

function get_home_path() {
	$home = get_option( 'home' );
	$siteurl = get_option( 'siteurl' );
	if ( ! empty( $home ) && 0 !== strcasecmp( $home, $siteurl ) ) {
		$wp_path_rel_to_home = str_ireplace( $home, '', $siteurl ); /* $siteurl - $home */
		$pos = strripos( str_replace( '\\', '/', $_SERVER['SCRIPT_FILENAME'] ), trailingslashit( $wp_path_rel_to_home ) );
		$home_path = substr( $_SERVER['SCRIPT_FILENAME'], 0, $pos );
		$home_path = trailingslashit( $home_path );
	} else {
		$home_path = ABSPATH;
	}

	return str_replace( '\\', '/', $home_path );
}

All the strings comparison or replacement will fail when they shouldn't.

Possible patch, remove the protocol:

function get_home_path() {
	$home = get_option( 'home' );
	$siteurl = get_option( 'siteurl' );
	$home = substr( $home, (strpos($home, 'https://') === 0 ? 8 : 7) );
	$siteurl = substr( $siteurl, (strpos($siteurl, 'https://') === 0 ? 8 : 7) );
	if ( ! empty( $home ) && 0 !== strcasecmp( $home, $siteurl ) ) {
		...

Thanks

[mark-k]

maybe it is good that this fails as this is a bad idea to have that kind of a configuration. you are sending the cookies encrypted when you are in the admin section but unencrypted when you are on the frontend. If part of the site is SSLed then once a user login all of the site should be SSLed for him.

Maybe the true bug here is that you can have a protocol mismatch between home and siteurl.

[dd32]

Maybe the true bug here is that you can have a protocol mismatch between home and siteurl.

WordPress actually has separate cookies for this, it has wp-admin only cookies, and a more generic logged in cookie for the front end.

This configuration is completely supported and should work, the fact it doesn't IS a bug.

[nacin]

Sorry, I misread dd32's comment.

[jeremyclarke]

+1 we are another site where this problem is causing havoc.

We use FORCE_SSL_ADMIN to secure the admin (logins etc) but don't secure the frontend because it's a lot more complicated to get all the frontend assets as https and thus avoid mixed content errors. (just stating the obvious as to why this config is desirable). Thus for us a home_url without https and a site_url with it is vital.

The outcome of this bug is that the permalinks page generates errors and becomes completely non-functional. No amount of chmod 777 will make .htacess writeable, which in many cases would mean people rendered unable to resave their permalinks (we had broken permalinks for awhile while I tried to track this down, TERRIBLE).

This also indirectly affects the WP-Supercache plugin which loses it's mind in mod_rewrite mode because it can't find the .htaccess file to assess or update it. I'm sure there are other things it breaks as well.

[carlalexander]

Ran into this issue today. A better fix along the lines above to remove the scheme entirely.

$home = get_option( 'home' );
$home = str_replace(parse_url($home, PHP_URL_SCHEME), '', $home);
$siteurl = get_option( 'siteurl' );
$siteurl = str_replace(parse_url($siteurl, PHP_URL_SCHEME), '', $siteurl);

That said providing a function that compares the two urls without the scheme might be more useful than doing it in the function itself.

[GregLone]

Doing a remove_url_scheme() function is not a bad idea actually.
See my diff file for the patch and the new function.

[GregLone]

Added the braces on the if statement.

[johnbillion]

25767.diff​ simply forces the http scheme onto both URLs so the string comparison/replacement will work regardless of scheme on either URL.

Moving to 4.0 for consideration as part of our SSL improvements.

[johnbillion]

In 28893:

Normalise the schemes used in get_home_path() so it returns the correct path for sites using SSL in the admin area but not the front end. Fixes #25767. Props GregLone for the initial patch.