WordPress.org

Make WordPress Core

Opened 8 weeks ago

Last modified 19 hours ago

#39497 new defect (bug)

Can't log out completely without closing my browser

Reported by: davidmlentz Owned by:
Milestone: 4.7.4 Priority: normal
Severity: major Version: 4.7
Component: Login and Registration Keywords:
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 (11)

#1 @fwdcar
7 weeks 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 7 weeks ago by fwdcar (previous) (diff)

#2 @fwdcar
7 weeks 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 7 weeks ago by fwdcar (previous) (diff)

#3 @GhostToast
5 weeks 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
13 days 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
13 days 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
13 days 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.


3 days ago

#8 @SergeyBiryukov
3 days ago

  • Milestone changed from 4.7.3 to 4.7.4

#9 in reply to: ↑ 4 ; follow-up: @johnbillion
24 hours 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
20 hours 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
19 hours 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 19 hours ago by birgire (previous) (diff)
Note: See TracTickets for help on using tickets.