Canfield Research Group

Drupal 5 changes the way the cookie domain is calculated. If you are using ports to direct traffic to systems behind a firewall (or for whatever reason) Drupal 5 will errantly add the port to the cookie domain. As far as I can tell the RFC that specifies how sessions are maintained (RFC 2109) does not allow port specifications. The PHP code used in Drupal 5 does NOT strip ports from the cookie_domain. The solutions I found are:

1. Comment or disable the code in session.php that modifies the cookie_domain. This makes it work somewhat like it did in Drupal 4.x from what I can tell.
2. Set the cookie_domain explicitly. I dislike this solution due to maintenance and site aliasing
3. Modify the session.php code to strip ports. All ports to the domain will thus be treated the same. Use virtual hosts if you want a different behavior. Add the following line (see full code below): $domain = preg_replace('/:\d+$', '');

if (isset($_SERVER['HTTP_HOST'])) {
  $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
  $domain = preg_replace('/:\d+$/', '', $domain);    // Remove port, it is not a valid part of a session domain
  // Per RFC 2109, cookie domains must contain at least one dot other than the
  // first. For hosts such as 'localhost', we don't set a cookie domain.
  if (count(explode('.', $domain)) > 2) {
    ini_set('session.cookie_domain', $domain);
  }
}

I prefer solution is 3 as it seems to be the "right" way. In ALL cases you will need to clear the cookies dealing with the domain otherwise strange results will occur. In my case the login appeared to work, but then I was logged out immediately since the session cookie was invalid and my browser rejected it on the returned page (guessing here, more research needed).

Since cookies are domain NOT port specific (as far as can tell from the RFC and based on testing in Drupal 4.7.6 and 5.1) this means that virtual domains should be used in addition to or instead of ports if logins will differ. I use ports to route to different systems behind a single IP firewall but each site has its own virtual host name.

There is a brief discussion on this type of problem (related to different software) at "the openacs web site": http://openacs.org/forums/message-view?message_id=103972

See also Please help fixing an elusive login issue