For quite some months, we've had a problem wherein, after some time, the mapped, front-end view (eg, http://www.domain.com, a mapped domain) behaves as if the editor/admin is not logged in (no admin bar or edit links etc), even though the back-end (eg, original.domain.com/site/wp-admin) remains accessible.
The problem can be remedied, in the short term, by deleting the cookies for domain.com. The user need not log back in again, just delete the root domain cookies and then reload the mapped domain page. However, the problem eventually reappears no matter how frequently this is done.
I'm unsure precisely what sequence of events lead up to this or how to reproduce the situation but, having rummaged around in the WP core and DM code, I can make an educated guess as to the cause. I've also appended a patch for consideration by the dev. But first, a little about our configuration:
• WPMS 4.3.1 in subdirectory mode; DM 220.127.116.11
• The network canonical domain ('original domain') is original.domain.com.
• Our primary site, http://www.domain.com, is a mapped domain† to site ID #2.
• We have additional sites to which other subdomains under the same root domain (eg this.domain.com and that.domain.com) are mapped, mainly for other languages etc.
• We also have completely unrelated domains mapped (eg example.com).
• wp-login and wp-admin are forced to original.domain.com because SSL is forced, and CDSSO is enabled asynchronously.
† There are historic reasons for this arrangement.
As you can see, we have a slightly unusual situation in that we have multiple subdomains under one common root domain that do different things within the same wordpress instance, which means that the (usually safe) assumption that domain.com is an exclusive alias for http://www.domain.com is not valid in our case.
Since deleting the cookies for domain.com fixes the problem (albeit short-term), the problem must be something to do with cookies, and therefore probably the way that COOKIE_DOMAIN is set. This is further hinted at by the fact that I see WP auth cookies set only in domain.com and original.domain.com, not http://www.domain.com.
Line 27 of domain-mapping/inc/sunrise.php strips off the www. prefix (if present) and COOKIE_DOMAIN is subsequently set to the bare root domain. Any other prefix (eg original.domain.com or this.domain.com or that.domain.com) is left intact. This explains why the cookies intended for http://www.domain.com are set in domain.com, where original.domain.com cookies are set where they should be.
Because the http://www.domain.com cookies are being set at the root domain level, future requests to original.domain.com will carry two sets of auth cookies — those set for original.domain.com plus domain.com. I don't know what WP will make of this, but it is clear that any subsequent‡ Set-Cookie headers will update only original.domain.com, at which point the cookies in domain.com become stale and visits to the mapped front end will behave as if the user is not logged in.
‡ since the expiration date is part of the auth hash, I assume WP periodically refreshes auth cookies so that subsequent auth cookie validation passes. This may explain why deleting the root domain cookies works, but only for a limited time.
We need to prevent DM's sunrise code from setting root domain cookies, but sunrise.php provides no way of altering this behaviour.
I'm not really sure why WP auth cookies need or should be set at the root domain in the first place, not least because it means that those cookies will be sent to other applications hosted under the same domain (security leak), and they may needlessly interfere with caching solutions like Varnish.
ETA: Another reason not to set root-level domain cookies is that doing so causes unwanted interaction between authorisation on a staging network and the production network when they are hosted under the same domain.
If the canonical mapped domain contains the www. prefix, then it seems reasonable to set the cookies there because requests to the bare domain will get redirected to the canonical domain anyway. Conversely, if the canonical domain is bare, then requests with the www. prefix will be redirected to the canonical domain where the cookies will be set.
Therefore, I propose that sunrise.php be modified so that cookies are always set in the requested domain (experimentation suggests that the auth cookies will get set in the canonical domain, even if the original requested domain is the non-canonical alias). The following patch accomplishes that, while preserving the behaviour of the query for a mapped domain with and without the www. prefix.
--- sunrise.php.orig 2015-11-29 19:02:56.666989030 -0600 +++ sunrise.php 2015-11-29 14:38:02.608550991 -0600 @@ -25,7 +25,7 @@ } $using_domain = strtolower( preg_replace( "/^www\./", "", $_SERVER['HTTP_HOST'] ) ); -define( 'COOKIE_DOMAIN', $using_domain ); +define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); $s_e = $wpdb->suppress_errors();
Initial testing shows that:
• requests to the bare domain.com get redirected to http://www.domain.com,
• requests to http://www.domain.com now set cookies in that domain and
• and requests to any other subdomain under domain.com get cookies set there, just is current behaivour.
• the more usual case where http://www.example.com and the bare root domain are aliases for and map to same site continue to work with or without the www. prefix, being redirected as appropriate.
I deployed this patch this morning and I will update this ticket over the coming days with any news as comes to light.
In the meantime, I'd value feedback from the dev as to whether this patch will make it into the next release or, if not, whether they have an alternative proposal and what we will need to do to make use of it.