WordPress MU

Logout does not work when logging in through the root of the site.

A quick note about my setup: All blogs are on my.domain.com (yeah, that's not really the domain) and each blog is in a subdirectory of that. So my wp-config.php has:

define('VHOST', 'no');
$base = '/';


I did some hunting and found the wp_clearcookie function in wp-includes/pluggable.php as my first port of call. I do in fact see all 4 Set-cookie headers being sent, which would normally force the cookie to be erased:

Set-Cookie: wordpressuser=+; expires=Sat, 13-Aug-2005 18:42:19 GMT; path=/adam/; domain=.my.domain.com
Set-Cookie: wordpresspass=+; expires=Sat, 13-Aug-2005 18:42:19 GMT; path=/adam/; domain=.my.domain.com
Set-Cookie: wordpressuser=+; expires=Sat, 13-Aug-2005 18:42:19 GMT; path=/adam/; domain=.my.domain.com
Set-Cookie: wordpresspass=+; expires=Sat, 13-Aug-2005 18:42:19 GMT; path=/adam/; domain=.my.domain.com


So in the above example, the user's name is 'adam' and the blog path is 'adam'. I went to http://my.domain.com/ and logged in from there (i.e. I didn't log in from http://my.domain.com/adam/ in which case everything would have worked fine).

So in the example above, logout obviously does not work, since the cookie was originally created with path of '/' but wordpress is asking for the cookie belonging to the path /adam/ to be deleteted.

In the setcookie calls (from wp_clearcookie), SITECOOKIEPATH is derived from a regex against get_settings('siteurl') and the option_value 'siteurl' in the database (for the user 'adam') is 'http://my.domain.com/adam/'.

My guess is that the correct behavior is for wpmu to be more careful about setting the path of the cookies when they are originally set?

On second thought, is there a reason that the cookies could not always just be set to the domain (and base path) of the site? In my case above, all cookies would be for domain .my.domain.com and path /. I could see why that might annoy some people with a domain vhost setup, but in the example above, I don't see any downside.

I've had trouble logging out as well.

I understand too little about cookies etc. to say anything usefull about possible causes...

Hmm, apparently this is quite easy to hack in my case. For anyone else interested, just open wp-includes/pluggable.php and edit the wp_setcookie and wm_clearcookie functions. I commented out the pair that set/remove the cookies with the sitecookie paths, and then hardcoded the path of '/' to the other two set/remove cookies. If your blog is rooted at a point other than /, say /blogs/, you'd obviously want to hardcode that value instead of / (though hardcoding / shouldn't really hurt either...it just means that potentially other webapps on that host could steal the cookie, and you can't run another wordpress installation without the cookies conflicting).

I suppose it wouldn't be hard to write a plugin to do this instead of hacking the functions themselves. Ahh well, hopefully either someone who understands the codebase better (and can explain why in the world the siteurl param isn't set to /) will fix this, or I'll get time to explore the codebase...

So...umm...think I should file this as a bug? Is there a development mailing list or anything? Maybe this isn't actually a bug? Thoughts?

I understand that this is OSS and all (i.e. no guarantees of support or bugfixes), but I've already put in a bit of work tracking this down, and I'd even be willing to do more work and come up with a real patch (as opposed to my ugly hack above) if only there were a way to make sure that
a) my work isn't duplicating other work already being done in this area
b) my work would be accepted (provided it passes muster, etc...)
c) someone can tell me where to send a patch, how the development process for mu works, etc...

I'm affected by this issue and I'm using paths rather than domains - eg:

http://citrite.org/blogs/samj

I can only log out from http://citrite.org/blogs/wp-login.php?action=logout, not http://citrite.org/blogs/samj/wp-login.php (in which case the logout request is ignored and I'm taken back to my control panel).

This is almost certainly related to the [SITE]COOKIEPATH variable[s] referenced in wp_clearcookie, and I consider this to be a fairly security issue (save that we shouldn't be setting usernames and passwords to cookies in the first place).

function wp_clearcookie() {
setcookie(USER_COOKIE, ' ', time() - 31536000, COOKIEPATH, COOKIE_DOMAIN);
setcookie(PASS_COOKIE, ' ', time() - 31536000, COOKIEPATH, COOKIE_DOMAIN);
setcookie(USER_COOKIE, ' ', time() - 31536000, SITECOOKIEPATH, COOKIE_DOMAIN);
setcookie(PASS_COOKIE, ' ', time() - 31536000, SITECOOKIEPATH, COOKIE_DOMAIN);
}

As anticipated, the path is including the users' subdirectory:

Set-Cookie: wordpressuser=+; expires=Mon, 15-Aug-2005 10:52:56 GMT; path=/blogs/samj/; domain=.citrite.org

Set-Cookie: wordpresspass=+; expires=Mon, 15-Aug-2005 10:52:56 GMT; path=/blogs/samj/; domain=.citrite.org

Set-Cookie: wordpressuser=+; expires=Mon, 15-Aug-2005 10:52:56 GMT; path=/blogs/samj/; domain=.citrite.org

Set-Cookie: wordpresspass=+; expires=Mon, 15-Aug-2005 10:52:56 GMT; path=/blogs/samj/; domain=.citrite.org

It appears the offending code is in wp-settings.php, specifically the use of the 'home' and 'siteurl' settings:

if ( !defined('COOKIEPATH') )
define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_settings('home') . '/' ) );
if ( !defined('SITECOOKIEPATH') )
define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_settings('siteurl') . '/' ) );

The side effect is that if you log in from the main blog and browse to your own then you can't log out from your own. The inverse however it seems is not true - that is it seems if we were to use the 'path' field from the 'site' table the problem would be resolved:

mysql> select * from wp_site
-> ;
+----+-------------+---------+
| id | domain | path |
+----+-------------+---------+
| 1 | citrite.org | /blogs/ |
+----+-------------+---------+
1 row in set (0.06 sec)

Indeed, that looks like a good place to get the setting from. I don't know enough about the data in the wp_*_options tables, but it would seem that the setting for siteurl should be the same as that value. Otherwise, what's the point of separate siteurl and home settings, if they both point to the same place (unless it's just legacy from WordPress core, to stay as close to the original source tree as possible). Any developers on here?

Obligatory bug tracker link:
http://trac.mu.wordpress.org/ticket/125

Just a quick update for anyone interested, this is now fixed in the latest code.