Can't log out completely without closing my browser

[davidmlentz]

I click Log Out from the WP Admin panel. I see the Failure Notice page confirming that I want to log out. I confirm, but if I navigate back to /wp-admin, I'm still logged in.

Problem occurs when we use WP Core 4.7. Problem does not occur on WP Core 4.6.

Problem occurs when all plugins are deactivated and uninstalled.

Problem occurs on more than one theme.

(This is described by another user here: ​https://wordpress.org/support/topic/4-7-multi-network-issues/)

[fwdcar]

Can confirm this behavior as well.

Things to note from thread referenced by davidmlentz in his description: ​https://wordpress.org/support/topic/4-7-multi-network-issues/

1) This appears to occur only on sub-sties (not the root) of a multisite install.

2) Setting WP_SITEURL to anything, for example: define( ‘WP_SITEURL’, ‘USELESS-JUNK’ ); fixes this problem. Not sure if doing this breaks other functionality but it is interesting.

edit: same problem in 4.7.1 RC1.

DC

[fwdcar]

somehow I inadvertently changed the version to 'trunk'. It's 4.7 which has the problem. sorry.

[GhostToast]

I can confirm encountering this issue on not a multi-network but a single network multisite. Troubles logging out (end up at WordPress Failure Notice

"You are attempting to log out of {sitename}
Do you really want to log out?"

Or login redirect loop with reauth=1 if I happen to be logged out already.

[birgire]

I can also confirm this on a single network multisite with subfolders (not subdomain).

Additionally I store the WordPress core in it's own subfolder

/wp
/wp-content
index.php
wp-config.php

Just got flooded with user notices after upgrading from 4.6.x -> 4.7.x where users:

• were not able to preview drafts - Not found 404 status
• have to log into each subsite separately
• can't logout because of 403 status from wp_nonce_ays() (ays = are you sure)
• admin bar not visible on the frontend because is_user_logged_in() is false on the frontend
• nonce verification problems

These issues seems to be all connected.

Let's compare the wp_cookie_constants() in WP version 4.6.3:

/**
 * Used to guarantee unique hash cookies
 *
 * @since 1.5.0
 */
if ( !defined( 'COOKIEHASH' ) ) {
        $siteurl = get_site_option( 'siteurl' );
        if ( $siteurl )
                define( 'COOKIEHASH', md5( $siteurl ) );
        else
                define( 'COOKIEHASH', '' );
}

and in version 4.7.3:

/**
 * Used to guarantee unique hash cookies
 *
 * @since 1.5.0
 */
if ( !defined( 'COOKIEHASH' ) ) {
        $siteurl = get_site_option( 'siteurl' );

        if ( $siteurl )
                define( 'COOKIEHASH', md5( $siteurl ) );
        else
                define( 'COOKIEHASH', md5( wp_guess_url() ) );
}

where we see that empty string '' has been replaced with wp_guess_url().

On my install the

get_site_option( 'siteurl' )

seems to be empty and COOKIEHASH not manually defined.

So the problematic line for my install seems to be this one:

define( 'COOKIEHASH', md5( wp_guess_url() ) );

because on the front-end it's

http://example.tld/wp

but within the backend it's

http://example.tld

resulting in two different cookie hashes.

To avoid it we can either define in wp-config.php:

define( 'COOKIEHASH', md5( 'http://example.tld' ) );

or as suggested by @fwdcar to define WP_SITEURL that circumwents the url guessing in wp_guess_url().

Hope it helps.

ps: Next I should probably investigate why get_site_option( 'siteurl' ) is empty.

[SergeyBiryukov]

Appears to be a regression introduced in [38619].

[birgire]

Here are few examples to understand how wp_guess_url() works for my install:

Frontend:

example.tld

        - $_SERVER['PHP_SELF'] : /wp/index.php
        - $path : /wp
        - $url : http://example.tld/wp

example.tld/site1/

	- $_SERVER['PHP_SELF']: /wp/index.php
	- $path : /wp
        - $url : http://example.tld/wp

Backend:

	
example.tld/wp-admin/index.php

	- $_SERVER['REQUEST_URI']: /wp-admin/index.php
	- $path : 
        - $url : http://example.tld

example.tld/site1/wp-admin/index.php

	- $_SERVER['REQUEST_URI']: /site1/wp-admin/index.php
	- $path : /site1
        - $url : http://example.tld/site1

This part of wp_guess_url() is of relevance here for constructing the $path variable:

// The request is for the admin
 if ( strpos( $_SERVER['REQUEST_URI'], 'wp-admin' ) !== false || strpos( $_SERVER['REQUEST_URI'], 'wp-login.php' ) !== false ) {
	$path = preg_replace( '#/(wp-admin/.*|wp-login.php)#i', '', $_SERVER['REQUEST_URI'] );
 // The request is for a file in ABSPATH
 } elseif ( $script_filename_dir . '/' == $abspath_fix ) {
	// Strip off any file/query params in the path
    $path = preg_replace( '#/[^/]*$#i', '', $_SERVER['PHP_SELF'] );

...

where in the end the url is constructed with:

$url = $schema . $_SERVER['HTTP_HOST'] . $path;

[johnbillion]

Replying to birgire:

ps: Next I should probably investigate why get_site_option( 'siteurl' ) is empty.

This is the root cause of the problem. That value shouldn't be empty post-installation.

[fwdcar]

Replying to johnbillion:

Replying to birgire:

ps: Next I should probably investigate why get_site_option( 'siteurl' ) is empty.

This is the root cause of the problem. That value shouldn't be empty post-installation.

Perhaps the fact that we can put gibberish in WP_SITEURL is a clue. I always wondered why

define( ‘WP_SITEURL’, ‘USELESS-JUNK’ );

appeared to solve the problem without breaking anything else. Just a thought...

[birgire]

Replying to @fwdcar:

A non-empty WP_SITEURL short circuits the wp_guess_url().

In /wp-includes/ms-default-filters.php we have the following:

// WP_HOME and WP_SITEURL should not have any effect in MS
remove_filter( 'option_siteurl', '_config_wp_home' );
remove_filter( 'option_home', '_config_wp_siteurl' );

that could explain why a gibberish WP_SITEURL seems to not affect multisites, apart from removing the url-guessing fallback.

Replying to @johnbillion :

It seems that many multisite installs might be missing the siteurl option, from the wp_sitemeta table.

In my case I wonder if it's:

• because some plugin removed it or
• because something happened during the initial install or
• because something happened during the many upgrades.

This install is about 8 years old (created January 2009), so it started as a WordPress MU if I remember correctly ;-)

[swissspidy]

As discussed during bug scrub, reverting [38619] might be an option.

[johnbillion]

The multiple reported instances of networks not having a value in the siteurl option indicate either a bug during the upgrade routine or a years old bug that has persisted through versions without problem until now.

For 4.7.4, let's revert [38619]. The feature can be re-visited later if someone wants to pick it up.

[johnbillion]

In 40320:

Login and Registration: Avoid a potentially incorrect value for the cookie hash on multisite installations that don't have a value in the siteurl network option.

This reverts [38619].

See #34084

Fixes #39497

[johnbillion]

In 40321:

Login and Registration: Avoid a potentially incorrect value for the cookie hash on multisite installations that don't have a value in the siteurl network option.

This reverts [38619].

See #34084, #39497

Merges [40320] to the 4.7 branch.

[didithoe]

After upgrade to 4.7.4 , logged user in multisite is force to relogin because it suddenly logout. Is it normal because of the upgrade ?

[johnbillion]

@didithoe Usually users will not be logged out due to an update. However in this situation the bug that was fixed was one that was causing incorrect cookie names to be used by WordPress. If your site was affected by this bug, then upon updating your users would have to log in again.