It looks like you have WP installed in a subdirectory. There’s a chance that the authentication mechanism doesn’t work with this particular setup.
When you switch to a user, does the wordpress_user_sw_olduser_ cookie get set correctly on the front end? And does the wordpress_user_sw_secure_ cookie also get set? If so, what’s the Path parameter set to for both? You can see these in your browser console.
WordPress is installed in a subdirectory, exactly.
The wordpress_user_sw_olduser_ does get set, the path is /. There is no wordpress_user_sw_secure_ cookie. There is a wordpress_user_sw_ cookie in admin and its path is set to /wp/.
Is the whole of your site served over HTTPS or just the admin area?
It’s either http or https on admin and frontend. I checked both though and it does not make a difference if it is http or https. I still think that it is a problem with a custom login url and WordPress installed in a subdirectory, since it is working when I manually change the url to include the full path to wp-login.php,
And does the wordpress_user_sw_secure_ cookie also get set?
The wordpress_user_sw_secure_ is of course there when using HTTPS… sorry. And wordpress_user_sw_ when accessing HTTP. So cookies are fine I guess and don’t seem to be the problem.
So here is a summed-up version of the problem:
The wordpress_user_sw_secure_ or wordpress_user_sw_ cookie is only valid for the WordPress directory. Since my wp-login.php is in the wp directory of my site AND I changed my login url from /wp/wp-login.php to /login the cookie is not there.
Changing SITECOOKIEPATH to COOKIEPATH for $auth_cookie_name fixes this. Do you see a problem in changing this? Security- or otherwise?
Thanks for all the info!
Changing SITECOOKIEPATH to COOKIEPATH might have unexpected consequences on multisite installations, but I’ll need to engage my brain properly and have a think about it. I’ll take a look in the next couple of weeks.
My – hopefully temporary – workaround looks like this:
add_action('wp_die_handler', function($handler) {
parse_str($_SERVER['QUERY_STRING'], $query);
if ($_SERVER['SCRIPT_FILENAME'] === ABSPATH . 'wp-login.php' && $query['action'] === 'switch_to_olduser') {
wp_redirect(get_bloginfo('wpurl') . $_SERVER['REQUEST_URI']);
exit;
}
return $handler;
});
So it hooks into the wp_die_handler, checks the requested php file and if the action is switching back to the old user. If yes it redirects to the ‘full’ wp-login.php (where the cookie is present).
I just remembered that you’re not the only person to report this: https://github.com/johnbillion/user-switching/issues/14
Hi, John and thanks. Your plugin saves a lot of time.
Just to mention I have the same problem…
(I am using https://wordpress.org/plugins/wps-hide-login/ for login redirection and have wordpress installed in a subdirectory as well).
Hi johnbillion,
I am also experiencing the ‘Could not switch users.’ issue and I think it is because my host installs WordPress by default in a wp subdirectory, because when I manually add wp to the URL it does work.
I have tried adding alpipego’s temporary workaround to my functions.php file but it is not making any difference.
This issue seems to have existed for a while. Do you plan to fix it? Can you help me in the meantime?
Thanks,
rt.