As described in the last post, Taffel.se is built from a number of WP blogs that share common user tables. After the next overhaul of the site is completed, users will be able to create user accounts that will work for commenting and the forum (which will be run on bbPress). Not only should these accounts be shared among the blogs that make up the site, but the user should not have to log in again to move from one blog to another. Here is how you can make this work.
I assume all of your sites have the same base domain such as taffel.se, matalskaren.taffel.se, kortomgott.taffel.se, etc.
WordPress tracks logged in users using cookies. By default, cookies only match the subdomain in which they are assigned. By setting the cookie domain to the root domain prefixed by a period, i.e. “.taffel.se”, you allow the cookie to be read by all subdomains. Set it by setting by putting
define('COOKIE_DOMAIN', '.taffel.se'); //replace with your domain, of course
in your wp-config.php (or in each wp-config.php, if you don’t have a shared installation).
I couldn’t for the life of me get this to work in my test environment until I read this post and learned that the cookie domain has to have an internal dot (.) in it to be accepted by the browser.
If you have different subpaths for different installations (i.e. taffel.se/site1, taffel.se/site2), you must also set the
COOKIEPATH to the root:
Now cookies can be read across subdomains, but they also have to share names and keys. WP 2.6 uses a multitude of different hash keys to increase cookie security – all of them have to be identical across installations. For starters, the keys
LOGGED_IN_KEY must be the same in each wp-config.php. Of course if you have a shared installation, they already are. These keys are used as salt when hashing a cookie value.
But these aren’t considered sufficient and WP also adds additional salt, which is stored as an option in the database, and is usually different for each install, which makes the cookie values incompatible. You can easily override these salts by defining
LOGGED_IN_SALT in your wp-config.php files. (You can generate suitable values here.)
Putting this salt in your wp-config.php sort of defeats the purpose of having additional salt; the point is that having the salt in different places makes it harder for would-be attackers to use. This doesn’t seem like an insane security risk, but there are other ways to get around the salt problem:
- Write a plugin that adds a ’salt’ filter that returns the same value for each blog.
- Synchronize the auth_salt and logged_in_salt options across the different blog tables.
- Write your own
wp_salt(). It’s in pluggable.php and can be overwritten without hacking source.
Finally, WP sets cookie names using
COOKIEHASH, which is generated in wp-settings.php by taking an md5 hash of the siteurl option. WP does not check to see if this is already defined, so if you define it in your wp-config.php, php will give you a notice when WP tries to define it again (if you have php set up to log such notices). This isn’t likely to give you any trouble, but if it disturbs your sensibilities you can either hack wp-settings.php (very easy, but every change to core code means more to remember when you upgrade) or individually define
TEST_COOKIE (all of which WP does check before defining) in your wp-config.php.
Now, clear your cookies (restarting your browser should do it) and try it!