WordPress.org

Make WordPress Core

Opened 8 months ago

Closed 5 months ago

Last modified 4 months ago

#39497 closed defect (bug) (fixed)

Can't log out completely without closing my browser

Reported by: davidmlentz Owned by: johnbillion
Milestone: 4.7.4 Priority: normal
Severity: major Version: 4.7
Component: Login and Registration Keywords: needs-patch revert
Focuses: multisite Cc:

Description

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/)

Change History (19)

#1 @fwdcar
8 months ago

  • Version changed from 4.7 to trunk

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

Last edited 8 months ago by fwdcar (previous) (diff)

#2 @fwdcar
8 months ago

  • Version changed from trunk to 4.7

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

Last edited 8 months ago by fwdcar (previous) (diff)

#3 @GhostToast
7 months ago

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.

#4 follow-up: @birgire
6 months ago

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.

#5 @SergeyBiryukov
6 months ago

  • Component changed from General to Login and Registration
  • Focuses multisite added
  • Milestone changed from Awaiting Review to 4.7.3

Appears to be a regression introduced in [38619].

#6 @birgire
6 months ago

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;

This ticket was mentioned in Slack in #core by jnylen. View the logs.


6 months ago

#8 @SergeyBiryukov
6 months ago

  • Milestone changed from 4.7.3 to 4.7.4

#9 in reply to: ↑ 4 ; follow-up: @johnbillion
6 months ago

  • Severity changed from normal to major

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.

#10 in reply to: ↑ 9 @fwdcar
6 months ago

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...

#11 @birgire
6 months ago

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 ;-)

Last edited 6 months ago by birgire (previous) (diff)

#12 @swissspidy
6 months ago

  • Keywords needs-patch added

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


5 months ago

#14 @swissspidy
5 months ago

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

#15 @johnbillion
5 months ago

  • Keywords revert added
  • Owner set to johnbillion
  • Status changed from new to assigned

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.

#16 @johnbillion
5 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

#17 @johnbillion
5 months ago

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.

#18 @didithoe
4 months ago

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 ?

#19 @johnbillion
4 months ago

@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.

Note: See TracTickets for help on using tickets.