By ksoonson on

I have been running 4.7 site for quite long time and upgraded to 5.1 recently.

But after that users of w3m started to complain that they are unable to log in.

They say that w3m rejects cookie. It's strange that there were no such problem with 4.7 and I found that drupal.org also works fine.

You will be able to test it easily by connecting to my site using w3m: kldp.org
I am not sure if this is an issue with drupal 5.1 or local server configuration error.

Any comment will be greatly appreciated.

Thanks.

⋅ Categories: Drupal 5.x

Comments

Anonymous’s picture

Anonymous (not verified) commented

It seems to be a problem related with domain attribute of the session cookie(PHPSESSID). I tried to connect some sites with the w3m, checking the received cookies:

1. http://drupal.org/ (or http://www.drupal.org/) : works fine. NO domain attribute in the cookie.
2. another site running drupal 5.1.x, maybe (http://jaspan.com/): works fine. no cookie domain.
3. http://kldp.org/ : cookie denied. cookie domain is ".kldp.org"
4. http://www.kldp.org/ : redirected to http://kldp.org/. ditto.
5. drupal 4.7.6 site with default settings (URL: "http://some.host.without.www.prefix/"): cookie denied. cookie domain is ".some.host..."
6. drupal 4.7.6 site with default settings (URL: "http://www.some.host.with.www.prefix/"): works fine. cookie domain is ".some.host..."

What I could guess from the results are:

1. It doesn't seem to be a 5.1.x only problem.
2. The problem doesn't occur in sites with URL hostnames prefixed with "www."
3. Some sites with hostnames without "www." prefixed don't make problems, because they just don't set cookie's domain.

According to the RFC 2109, cookie domain of ".kldp.org" doesn't 'domain-match' "kldp.org". So you can work around the problem by:

1. changing your site's hostname to "www.kldp.org",
2. setting cookie domain to "kldp.org" (see sites/default/settings.php), or
3. just not sending cookie domain. (by commenting out the cookie domain related stuff from the settings.php)

The last option may cause a problem if you are running other sites in the subdomains, I guess. :-)

----

The real source of the problem, I think, is the following routine in the sites/default/settings.php:

/**
 * We try to set the correct cookie domain. If you are experiencing problems
 * try commenting out the code below or specifying the cookie domain by hand.
 */
if (isset($_SERVER['HTTP_HOST'])) {
  $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
  // 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);
  }
}

Is there a good reason for removing the "^www." from hostnames?

ksoonson’s picture

ksoonson commented

Thank you very much. I just commented out that part at settings.php and hardcoded the cookie domain. Now it is working fine now. Thanks again.

Anonymous’s picture

Anonymous (not verified) commented

Sorry, but the second option may not work for your case, since your domain ("kldp.org") has only one dot(.) and w3m rejects such a cookie domain:

int
add_cookie(...)
{
    ...

    if (domain) {
        ....
        if (version == 0) {
            /* [NETSCAPE] rule */
            int n = total_dot_number(domain->ptr,
                                     domain->ptr + domain->length,
                                     3);
            if (n < 2) {
                COOKIE_ERROR(COO_ESPECIAL);
            }
        ...
    ...
}

The stuffs about the cookie domain seem to be not so clear... many specifications and standards, many implementations, ... :-(

ksoonson’s picture

ksoonson commented

I removed the hardcoding line and just commented that part at settings.php.
Now w3m works fine. Thanks very much.