Having stated the problem and now played further, I’ve got good news and bad news.
The good news is that there’s an action hook, ‘set_auth_cookie’, that gets called whenever the cookies are set, so if the stuff for which you want to authenticate is on the same server but at a different path, you can create a plugin (or maybe use functions.php in your theme?) with something like the following:
-
function your_unique_name_here_set_auth_cookie($auth_cookie, $expire, $expiration, $user_id, $scheme) {
-
setcookie(AUTH_COOKIE, $auth_cookie, $expire, '/path/to/your/stuff', COOKIE_DOMAIN);
-
}
-
-
add_action('set_auth_cookie','your_unique_name_here_set_auth_cookie',10,5);
The bad news is that if your WordPress install is at example.com/something and you want to use it to authenticate at portal.example.com, you can’t set a cookie for portal.example.com from a script on example.com, so your only choice would be to set a cookie with path / on .example.com (note the leading period), which completely breaks the security added by the separate cookies.
Hopefully, there’ll be a “part 3″ to this wherein I solve this last problem somehow, since that’s the setup I’m dealing with.
Trackbacks & Pingbacks 1
[...] as a followup to parts 1 and 2, per WordPress Trac ticket #7001, WordPress 2.6 has split up the login cookies into three [...]