Single Sign-on and SEO

Continued discussion from #132015: I often get "page not found" and #180514: Use fully-qualified domain names instead of subdomains?.

domain_grant_all() checks whether links on the current page (path) will be re-written. However, if SEO is turned on (#195366: SEO and Duplicate Content), requests to configured special pages are still re-written, since $seo overrides $check.

Because of that, Single Sign-on (and probably other exclusions) are broken.

Since SEO is absolutely senseless for special pages like cron.php and singlesignon/*, domain_grant_all() should have precedence at any time.

Attached patch fixes this (first) issue.

However, there's another show-stopper somewhere that completely breaks SSO. I should explain my rather advanced setup first:

• 2 domains: domain1.com, domain2.com
• Domain Access + Shared Sign-on
• Since domain1.com also serves subdomains, but SSO is not required for them (by setting the cookiedomain to domain1.com), I'm dynamically adapting $cookiedomain in settings.php:
  

  if (strpos($_SERVER['HTTP_HOST'], 'domain2') !== FALSE) {
    $cookie_domain = 'domain2.com';
  }
  else {
    $cookie_domain = 'domain1.com';
  }
  

  Thus, cookiedomain for domain2.com is always domain2.com, and cookiedomain for *.domain1.com as well as domain1.com itself is always domain1.com.

Now, if a user logs on to domain1.com and follows a link to domain2.com, she is not logged on and gets a 404 page not found by Drupal instead. Interestingly, the URL in the address bar contains domain2.com:
http://domain2.com/singlesignon/initial_check?slave_session=bj3dfsb4ab782umb7l7rolklo5&singlesignon_dest=http%3A%2F%2Fdomain2.com%2F

At first I thought this was a bug in SSO. But after some more debugging, I discovered that $_GET['q'] is empty in domain_grant_all() when above page is served. So Domain Access might be involved in that, too.
I don't understand how $_GET['q'] can be empty if the page request was clearly invoked with a path.

Gotta go to sleep now.