Login issue and fix for Drupal 5 HEAD and 4.7 HEAD

For multisite you have a different settings.php for each site so I'm not sure if that last patch is needed. Or, are you doing that in the case where there is no base_url set and Drupal automatically determines it?

Even if you have different settings.php you still need a different session name for each or you won't be able to stay logged in on your different sites.

Ah, my bad. I was reading session.name as session.cookie_domain. Just some code style / comment improvements then:

- Should bring "uncomment" to the line above in the first comment.
- Got some double spaces in the code and comments.
- Need a period on 2nd comment.

Query: Is this a wide-spread enough problem that we should make setting this value part of the install?

I can confirm that login problems have been generating hundred-long support threads (although I cannot confirm that the login problems have the same cause). A few core hacks float around as solutions for some. In most of the cases that I was involved a solution was found by stabilizing "www or no-www" and/or making the $base_url tolerant, and then clearing the cookie.

Overall, I think that Drupal is more sensitive to cookie problems than it should be, and that a solution with fewer places to uncomment settings would be preferable.

The log-in problems (www vs no-www) are unrelated to the session name problems (mutliple sites on one domain). The original poster seems to describe issues of the first kind, but provides a patch for the second.

Let's clear this issue up and split it into two please. The www issue can look like consistent log-in problems, if you are logging into "foo.com" but are being redirected to "www.foo.com". No amount of browser restarting is going to fix that.

It should be "fill in the *domain name* of your Drupal installation" not URL.

Couldn't we also set it our selves based on HTTP_HOST? Stripping off a leading www. prefix is easy and should address most common cases...

th merit of more commented out code which strips www is debateable. i think this is rtbc.

Hm. I think what Steven was suggesting was something on the order of:

$domain = str_replace('www', '', $_SERVER['HTTP_HOST']);
ini_set('session.cookie_domain', $domain);

Ummm, what about hosts named 'www.swwweeeetsite.com'? Need a ltrim() instead.

Rethought it, it should probably be a preg_replace that replaces '^www.' with '.' since HTTP_HOST could not have the www right? So even an ltrim() would mess up with a HTTP_HOST like wwworldofjellies.com.

I noticed that this second approach preserves subdomains. Not sure if this is good or bad. Probably good.

The patch was not right... for "www.example.com", the cookie domain was ".example.com", but for "example.com", the leading period was missing. I corrected this.

I also defaulted the check to on. This does no harm on sites that currently have no problems, it only gives them the benefit that their cookies suddenly are shared across www and no-www domains. At most, people may have to log-in again to get the benefit. All online references I can find show that the leading period works for cookie domains.

However, one thing I don't trust is the HTTP_HOST header. Isn't this Apache-specific? In any case, Drupal can be run in a variety of cases and we might set an invalid cookie domain, preventing log-in. So, I added a check to see if HTTP_HOST is set, only then, set the cookie domain:

/**
 * 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']);
  ini_set('session.cookie_domain', $domain);
}

Let's get this done. Committed to HEAD.

Only one problem remains: how to get this fix out to existing sites? Do we tell people to copy it over manually? Doing a rewrite of settings.php would be tricky as we have no guarantee of writability. Still, I suppose existing sites don't strictly need this fix. Sites like drupal.org already have their own www-prefix solution (redirects).

backported to 4.7

Doesn't this add a dot in front of subdomain URLs?

... subdomains, localhost and numeric.

I just tested on localhost and 127.0.0.1, and seems to be working fine.

The "." before the domain just means "anything.example.com"

It also worked ok with subdomains in both IE and Firefox2 (but I didn't have a problem before).

It seems like a pretty bad idea to share cookies across *all* subdomains by default. Isn't this going to be a sessions problem for people who have drupal installed on multiple subdomains (e.g. by default it will share the session id between groups.drupal.org and drupal.org)?

If I understand the code correctly, it does not strip the subdomain. I was just worried because it adds a dot in front of it.

Sites like drupal.org can stick to their current scheme of having domain-specific cookies. It is easily removed, and for existing sites, must be explicitly pasted into the existing settings.php file. So I would not worry about upgrading much.

However, I did just experience some local log-in issues and did the research (RFC 2109). We cannot use cookie_domain for scenarios such as http://localhost/:

   * A Set-Cookie with Domain=.com or Domain=.com., will always be
     rejected, because there is no embedded dot.

The current code generates '.localhost', which is clearly disallowed.

Also note this:

   * A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
     be accepted.

   * A Set-Cookie with Domain=ajax.com will be rejected because the
     value for Domain does not begin with a dot.

The first confirms my explanation above, the latter suggests that the previous patch was not standards compliant at all (although it is possible that some browsers still accept such cookies).

I added a check to not set a cookie domains of the form '.example', and use '.example.com' for normal cases.

By the way, i suspect webchick was not using the new code... you must regenerate settings.php after applying this patch ,if you are not using sites/default.

There seems to be trouble with nonstandard ports. People reported that removing the patch solved the problem.

See http://drupal.org/node/109572

ChrisKennedy's point is correct: setting the cookie domain to .domain.com will cause it to override all other PHPSESSID's for subdomains. This would, for instance, break drupal.org and groups.drupal.org.

Frankly, I don't think it's bad to have www.site.com and site.com have different cookies. This is standard behavior on the web.

-1

Does not happen with my subdomains. They all retain their separate cookies with or without this patch.

To figure out standard practice trends, I just sorted and checked my Firefox2 cookie file.

I found:
- 609 entries with .domain.tld or .sub.domain.tld
- 4 entries with .www.domain.tld
- 151 entries with domain.tld or sub.domain.tld
- 186 entries with www.domain.tld
I didn't have the time to try to figure out multiple cookies and which of them were intended for accessing different destinations or not, but there were several.

The fact remains that many people had a problem logging in without doing something to stabilize their cookie domain, so the previous state was not ok. The next thing is to evaluate/weight any new problems introduces.

I tried all of the above patches and none of them work for me. I can't login on any browser unless I reset the password. I am on a Windows server, could that be the problem?

More information is needed for figuring out what your issue is and whether it is even related to cookies. For example, some of the following questions may be relevant:

- Drupal version exactly?
- What do you mean you can't login? A message that username/password is not accepted or a login failure without any error messages? And what do you mean "reset the password"?
- What do you mean "a Windows server"? Is your web server Apache or IIS?
- Are you using a different port such as 8080?
- Can you check Firefox's cookies.txt file to see what cookie domain is used?
- Did you clear your site's cookie in your browser every time you applied any change to your cookie domain?

Ok, here are some more specifics:

1. I am on Drupal 5

2. When I try to login on the front-end and on the back in, it simply reloads the page and doesn't log me in. No error messages, it's as if I hit the browser refresh button. In order to login, I have to use the "request new password" link at the bottom of the login box to have the system email me a one-time use login. I can log in via that link, but once I log out, I can't log back in unless I repeat the "request new password" process over again.

3. I don't know if our server is Apache or IIS. We're using IXhosting.com, and we're on one of their Windows platforms. They've enabled PHP and MySQL on all their windows plans. I believe their server is Windows NT, but I don't know how to tell if they're using Apache or not.

4. I don't know how to tell what port we're on. It never gives me any information about ports. Is this something I need to set, or is there somewhere I can go to find this information out?

5. The cookie domain is the same as our domain, eg ".ourdomain.com. The client I'm doing this site for wants index.html to redirect to another domain while the drupal site is under development. So to access the drupal installation, I manually type ourdomain.com/index.php. I thought that was causing the problem, so I deleted the index.html, cleared out all the cookies and the cache, and I still cannot login. This is the case on both IE and Firefox.

I tried the patches listed in this thread, as mentioned earlier, and I still have login issues. Any other clues as to what could be causing this problem?

One more thing, we're using PHP 4. And the MySQL watchdog table reports that the database is creating a session for every login, but that doesn't reflect on the actual site.

I think there is an issue here with domain cookies

First, the assumption that your site is either a "www.sitename.com" or "sitename.com" ours is "www-intranet.sitename.com" and this code therefore produces ".www-intranet.sitename.com" which makes the more strict browsers (e.g. FF2) refuse to accept the cookie.

Secondly, you cannot login to multiple Drupal installations in the same domain. For example we could run separate Drupals for "www-intranet.sitename.com" and "www.sitename.com" and perhaps "portal.sitename.com" - to login to any of these require you to clear your cookies after each login.
We are running Drupal 4.74 on "www-intranet.sitename.com/it/docs" and Drupal 5.0 on "www-intranet.sitename.com/docs" and cannot login to both at the same time, we have to clear our cookies to change which one we are logged into.

I would propose that the 'sitename' be used for the cookie name, rather than 'PHPSESSID'

@orbit82: I think that your point (4) makes this a special case which is probably not easy to be handled by any default settings, especially since you redirect to another domain.

Things I would try:
- Look at the domain name used in the working link in the password recovery email, and try to make the cookie domain agree with that in your settings.php.
- Instead of using redirection tricks, consider using a subdomain for your development site, such as devel.example.com. That would keep things much simpler and internal links won't break when you move the site.
- And a different "lucky try": Try an all-english-lowercase username/password. If that works, it could be a database character set/collation problem.

But I have been out of topic here... I don't think it is ok for this to be discussed in this issue thread.

@ScarabMonkey: I have no problem logging in to my different subdomains using the .subdomain.example.com cookies in FF2, and I stay logged in to each one. The only thing I had to do was clear my browser cookies just once, when this patch changed the cookie domains,

So, if there is a bug, it must be located to something more specific to your setup before it can be fixed. BTW, I have all subdomains' $base_urls commented out.

CogRusty, I've tried your suggestions and it still doesn't want to work for me. I got rid of the redirect and it doesn't work. I also checked the cookie domain for the password recovery link and it's the exact same domain used whenever I tried to login before resetting the password. So it has nothing to do with the redirecting.

I had the same frustrating problem and found that commenting out the register_shutdown_function('session_write_close') line in includes/session.inc fixed it. I also posted this to the issue that added the line: http://drupal.org/node/93945#comment-183135

Thanks for the suggestion ChrisKennedy, but it didn't work for me. :( I just tried installing a test Drupal on a Unix/Linux server, and I had absolutely no problems logging in. So I'm sure the login isn't working for me because I'm on a Windows server. Our host does have PHP and MySQL on its Windows servers, but it seems that Drupal doesn't run properly on Windows. I talked to the host and they said to reinstall it. I did that, and I still can't login. The host says they won't offer any more support for 3rd-party software. So I'm at a complete loss as to how to fix this problem, besides switching to a linux platform.

@CogsRusty
Thanks for that, although we are running 2 instances on the same server and have this issue (so I have had to specify their base_url otherwise they don't work at all.

It's nothing to do with a windows server. I have the same problem on my linux machine.
I have many sites this way:
127.0.0.1/drupal
127.0.0.1/test
127.0.0.1/myproject ,
etc.

Up until I updated Drupal-5, I could stay logged in in all site at once.

With the new code in settings.php, I can't login anymore using Konqueror. Actually, the same happens to me as described above: I do get logged it (no error message upon login) but when the page reloads, I am not logged in (i.e. the cookie was not accepted).

I must remove the added code to be able to log in... but then, compared to before I updated, I cannot stay logged in all the sub-sites at the same time. If I log in on one side, I get logged out on the other...

Also, this seems to be browser-specific. With the new code, I can log in with FF, but not with Konqueror 3.4.2.

For me, the solution was twofold:
1) comment out the added code.
2) use http://tw.php.net/manual/en/ref.session.php#ini.session.cookie-path
and add:

ini_set('session.cookie_path',        '/myproject');

My personal contribution: I tried setting up a fresh installation of drupal 5, on Windows XP sp2, with Apache 2, running on port 81, Mysql and PHP5. I also experienced problems logging in. I was able to create admin. user, but when I logged out, I wasn't able to log in again, neither with Firefox (2) or I.E. (6).

I discovered that starting my Apache server on standard port 80 I had no more login problems ( I logged in normally). Then I started again the Apache server on port 81 - and again cannot login.

Note than on the same server, I already run several Drupal 4 (4.7.5 and older) websites with no problems at all.

I was able to solve my problem including these lines in settings.php:

ini_set('session.cookie_domain', '.mydomain.it');
ini_set('session.cookie_path', '/mysitename');

Note that including only the "cookie_domain" line solved my problem, but with I.E. only! The second line solved the problem with firefox too.

I also tried setting up a second website using the multisite featured. I also had login problem with the newwebsite; to solve it, again, I had to insert the previous lines, but I also had to change the second line to:

ini_set('session.cookie_path', '/myothersitename');

Again, it solved the problem. I suppose in the future Drupal 5 code will make not necessary to modify each settings.php manually :-)

Hope this helped - thanks to all!

See this http://drupal.org/node/64726. I've to clear FF cache to be able to login again. No problem with IE.

I'd just like to confirm that the introduced cookie_domain check broke logins with Safari (which shares it's code with Konqueror) on one of my sites but not on a couple of other ones. The symptoms are exactly as described in #54 (except that I don't have separate sites in subdirectories) and the solution in my case too is to comment out the code.

The site that broke has the following specifications:
Drupal 5.0 / Ubuntu (Dapper Drake) / Apache 2.0.55 / PHP 5.1.2

However the important clue is probably that I'm using an IP address, not a domain name, for the time being. I suspect that once I start using a domain name the problem will disappear. Also, I'm accessing the site through a VPN connection, but I don't think that should have anything to do with it.

@orbit82 IXhosting.com or ixwebhosting.com ?

I couldn't find an IXhosting.com, so I assume you're with the latter. run a php info and check the Hostname:Port. You'll see if in the first block of apache specifics, about 5th or 6th item. Look for:
Hostname:Port :: yourdomain.com:80 where the number at the end is your port.

ixwebhosting for my D5.1 site on linux is at port 80. Might be different on their windows plans.

an easy phpinfo in your browser: drop this in a new file yoursite.com/phpinfo.php

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">


<head>

</head>
<body>
<pre>
<?php
phpinfo()
?>
</pre>
</body>
</html>

Point your browser at it and take a look. As said above. port is listed in a Hostname:Port pair about 5th or 6th line down.

subscribing

Another way to deal with this is to get rid of the cookie domain code and have separate settings files for each possible variant of your domain that 301 redirect to a canonical version.

subscribing

Closing this issue.

This issue was about placing code in settings.php for automatically parsing out the cookie domain, so that www.example.com and example.com both have the same cookie domain, in order to prevent browser login problems.

If you are having other login problems, please open separate issues for them, but ONLY if it's accompanied by a DETAILED description of what is going on and how to reproduce it (think Elusive login issue detailed).

The fix in #51 solved it for me. I'm running PHP 4.4

Subscribing...