For quite some time now, we have been getting sporadic reports of mysterious login problems, mostly with Internet Explorer but sometimes with other browsers on other OSes. Read on the full post for updates, last on Feb 9th.

There are a other few known problems with proper fixes, and those include:

  • not able to be logged in to multiple sites on the same domain at once. The fix for this is: ini_set('session.name', 'examplecom') (note that session name can only contain alphanumeric characters.)
  • login works, but you still appear to be logged out. The fix for this is to just press reload.
  • Users login to www.example.com but don't show as logged in on example.com. The fix for this is to put in an .htaccess redirect so that www.example.com automatically becomes example.com. See Login doesn't work or must be done twice in the Troubleshooting FAQ.
  • You are using an older version of Drupal and PHP 5.2. The fix for this is to update to the latest stable version, which has a fix.
  • Using the globalredirect module, which had a known bug regarding logins. Fix is simple: update to latest -dev versions, the official release is still broken.

However, if you have tried to log in to just one site, and even a reload fails to show you as logged in, and multiple host names are not the issue, then you are facing this problem. If you are BOTH a) able to reproduce it reliably and b) are comfortable with editing Drupal files, then please comment on this issue and I will try to help you find a solution.

Help by answering the following:

  1. What specific browser and OS has the problem? (including Major / Minor version)
  2. Does another browser on the same OS have the same problem?
  3. Does the same browser on a different OS have the same problem? You might not be able to check this, but for example if you are on Windows, and trying a Linux Live CD is not a problem for you, then please try.
  4. Does the browser have any toolbars/spyware that could be interfering?
  5. Does clearing cookies/history/files help?
  6. Does a browser reinstall help (if the browser is OS-bound then an OS reinstall)?
  7. What other troubleshooting measures have you tried?
  8. Do you utilize a firewall? Does switching it off help?

Please note that off-topic or 'me too' posts will be deleted. There have been far too many forum topics and issues on this problem that have become 200+ reply balls of confusion; let's fix this once and for all. Please only comment if you want to help fixing this problem -- please note that I will help you find a solution. I am not affected myself, so I will not spend lots of time to debug, but I will spend enough time to lead you.

Update (Feb 6th): Now it seems we are facing two problems at least, not one. One is users simply unable to log in. The other is that you need to restart the browser in order to be logged in. I would like ask everyone to play with the three Cache-Control lines in bootstrap.inc, drupal_page_header and drupal_page_cache_header . Comment out all, does this help? If yes, comment out less, and find out which one helped for real.

Update (Feb 9th): I more and more believe that there is no mystery issue at all. This whole cookie business is a hack on a stateless protocol and simply because of the number of Drupal users a very small percentage is biten by various problems. Sometimes more than one problem. It was made worse by the PHP 5.2 fiasco. This issue probably contains all problems and fixes or so I hope. But there is nothing to fix in Drupal. I might be wrong, only time will tell.

Comments

nickistre’s picture

I just hit on this issue in the last few days.

I just noticed that it's still not working on my desktop at home (Firefox 2.0.01 on Windows 2000 Pro); it still has the "Login with correct username and password but still logged out without an error" issue going on it. If I type in an incorrect login and password, the site responds with an "unrecognized username or password" error like it should.

Here's my Server information:
O.S.: Debian 3.1 Linux
Server: Apache/2.0.54
PHP: PHP 4.4.4-0.dotdeb.1 (CGI)
Drupal: Drupal 4.7.6

Let me answer the questions as best as I can:

# What specific browser and OS has the problem? (including Major / Minor version)
# Does another browser on the same OS have the same problem?
# Does the same browser on a different OS have the same problem? You might not be able to check this, but for example if you are on Windows, and trying a Linux Live CD is not a problem for you, then please try.

I had this issue on all the browsers on all the systems I tried. Firefox 2.0.0.1 and Internet Explorer 6.0 on Windows 2000 Pro, Firefox 2.0.0.1 on Windows XP Home, and Firefox 2.0.0.1 on Linux (Ubuntu 6.06.1). Setting the "set_ini('session.name', 'example.com')" seemed to have fixed this issue at the time, but I just noticed that Firefox 2.0.0.1 on the Windows 2000 Pro is repeating the same issues (but all the other browsers work on the same system and all of the other O.S.es work fine).

Symptoms were attempting to log in with a correct username and password, but the site simply returns to the page but logged out. Pressing "Reload" doesn't fix it. Clearing cookies didn't fix it. The strange thing was before the "set_ini" fix above, I was able to login to a page by attempting to login, then closing and opening the browser would end up with me logged in to the page (Only tested with Firefox 2.0.0.1, but on both Windows 2000 Pro and Linux). Very strange.

# Does the browser have any toolbars/spyware that could be interfering?
# Does clearing cookies/history/files help?

Before the "set_ini" fix above, no. This time, for Firefox 2.0.0.1 on the Windows 2000 Pro Machine, just clearing cookies fixed it.

# Does a browser reinstall help (if the browser is OS-bound then an OS reinstall)?

Unknown

# What other troubleshooting measures have you tried?

I attempted a number of suggestions on this thread before the above mentioned fix. Let me see if I can remember which ones:

1 - I've tried deleting cookies and history
2 - per this comment, I inserted this line in settings.php: "ini_set('register_long_arrays', 1);" - Didn't work. Did not undo this one.
3 - From this comment, inserted "set_ini('session.auto_start', 0);" into settings.php - no change, did not undo this one.
4 - Per this comment, attempted to hack the user.module to check that the user is not 0 - Didn't work, Undid this one.
5 - Per this comment, attempted to hack index.php by inserting "$GLOBALS['tempUser'] = $user;" after drupal_page_footer(); - Didn't work, Undid this one.

Hope this helps. Keep in mind that I haven't hit this issue on a Drupal 5.1 installation on the same server (different domain). Feel free to ask if I left anything out.

Thanks,
Nick

ADD: Oops, didn't read the last couple of lines. Feel free to delete this post if it clutters this up.

chx’s picture

If you have answered to this post, I presume you are ready to work with us to fix it.

So, you have a domain with a Drupal 4.7.6 that causes this login issue. Please try with a clean 4.7.6 install on the domain or a subdirectory and see whether the problem still provides itself. I presume yes. Now add set_ini('session.name', 'examplecom') to settings.php. Record HTTP response headers when posting to user/login before and after the fix. wget -S shows the HTTP headers, its manual tells you how to do a HTTP post.

Thanks for the cooperations.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

nickistre’s picture

Sounds good. I was able to reproduce this by removing the "set_ini('session.name', 'example.com')" on my main site; I'll see if I can reproduce this with another install on the same server. If you want, I can give you ftp access to play with it.

chx’s picture

I tried to make this very clean in the original post: I am not fixing this. I will give advice, lead on but this is not something I will fix (because I do not have the time).

You do not necessarily need to reinstall, seems you have a setup where it's broken and a simple change where it's fixed. Compare HTTP response headers.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

nickistre’s picture

I feel like a fool now... I just realized when this started happening, and the proper fix is, as you've mentioned it right in your first post.

not able to be logged in to multiple sites on the same domain at once. The fix for this is: ini_set('session.name', 'examplecom') (note that session name can only contain alphanumeric characters.)

It should have clued me in when I said:

Keep in mind that I haven't hit this issue on a Drupal 5.1 installation on the same server (different domain).

I was wrong here, it was a different sub-domain. Same domain though. This problem on my anime weblog (anime. subdomain) started when I put in a drupal install on my main subdomain (www. subdomain).

I apologize for wasting your time...

chx’s picture

The multisite login problem manifests yourself in being logged out when navigating to the other site. So if you can't log in while not browsing the other site, then you are bitten by this problem.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

StevenPatz’s picture

I too had run into this problem, I'd log in, go to a page, and be logged out. I noticed that if I allowed the devel.module to finish doing it's thing, I was able to stay logged in.

chx’s picture

What are you talking of? You need to elaborate.

But, if you can't stay logged in (it's not the reload or other problem in the orginal post) with devel module switched off and can with devel switched on and "doing it's thing", then you might hold the keys to this issue.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

StevenPatz’s picture

1. Log in to site.
2. Devel module would display queries that were run.
3. If I clicked on a link before all that info was displayed, I would be logged out. Refreshing would not log me back in.
4. If on the other hand I let all the info from the devel module display, then click on a link, I would stay logged in.

rstoeber’s picture

Server:
Red Hat Enterprise Linux ES release 4
Apache/2.0.52
PHP 4.3.9
MySQL 4.1.12

Client:
Windows XP (SP2)
Firefox 2.0.0.1
Internet Explorer 7.0.5730.11

Upgraded from 4.7.5 to 4.7.6 by unpacking the new files, copying the settings file into the new directory, copying my extra modules from modules/contrib into the new directory. update.php ran with no errors.

After the update whenever I try to log in as any VALID user I just get the login page back with a blanked form. If it try to log in with a bad password or user ID it gives me the proper error message.

Spent all of the past weekend trying the various suggestions above, as well as suggestions from other postings, but nothing has helped. Clearing cache, sessions, history tables and restarting Apache doesn't help. Clearing my browser cache and cookies doesn't help. Didn't try reinstalling my browsers or operating systems.

Since I'm not getting an error message when using a valid User ID and password I assume that I really am getting logged in, but something in the menu/page display code isn't getting the message. So I've been trying to follow the log in process to see what's breaking. I found a function called user_load in the user.module. It looks like that function loads an array with all the user's information IF the user is successfully logged in.

I put a var_dump($user) in there at the very end, just before the return statement. The array is clearly populated with my information. So at that point at least the system knows I am logged in as a valid user. But somewhere after that the system thinks I'm an Anonymous user again.

Any idea what I should try next? It's Monday morning and my users are going to be really upset if they can't log in soon. I'd be happy to pay for someone's time to look at my system if you think it will help debug this problem for everyone.

taylanpince’s picture

We are experiencing this issue on Drupal 5 with our development platform. We are using different ports (8888, 8889, etc.) to access different sites, and this causes the login issue to occur on every browser with Drupal 5. The only way to fix it is to comment out the ini_set('session.name', 'examplecom') call in the settings.php file.

However, even after removing that some versions of Internet Explorer 6 continue to have the login issue. I am assuming this is the same thing we were seeing in earlier versions of Drupal. Please note that it is only some installations of IE6, not all. I am not sure if it is related to the Windows installation, or the security settings. I couldn't find the exact cause after a lot of tests.

robb’s picture

I had the same problem with Drupal 5.x. 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+$', '');     // 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: http://openacs.org/forums/message-view?message_id=103972

zero2one’s picture

If you have problems with portnumbers with drupal 4.7.x:
Comment out the cookie domain correction code in the /settings/default/settings.php file.

/**
 * 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);
  }
}*/
robb’s picture

Oops, old code fragment got into the post, sorry. Th preg_replace statement is incomplete. It should be:

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);
  }
}
rstoeber’s picture

On the off chance that the log in problem is related to a multi site configuration I just did a completely clean install of 4.7.6.

1) Unpacked the original files
2) Changed the references to example.com in the .htaccess file to my own domain.
3) Copied my database connect string into sites/default/settings.php
4) Copied my theme into themes/
5) Shut down Apache
6) Logged into MySQL and deleted all rows from tables cache, sessions, history
7) Cleared my browser cache and cookies
8) Started Apache

Note that I didn't even copy any extra modules into this setup. I know that would cause problems with certain functions, but I don't think any modules touch the login process.

So I now have a single site, configured as the default. Other than the modified gworks theme everything should be clean.

Guess what. I still can't log in. All symptoms are the same. Entering a bad user/password generates the proper error message. Entering a valid user/password redraws the login page with no error message.

rstoeber’s picture

I just discovered that I can solve my login problem by disabling the ZoneAlarm firewall on my computer. After shutting that off I was able to log in/out about a dozen times with no problem.

No idea why that would happen. I made sure that my web site was specifically listed with nothing blocked in the ZoneAlarm configuration.

As soon as I turn the firewall back on I'm blocked from my site again.

Can anyone else using ZoneAlarm confirm this behavior?

UPDATE:

After some more testing it seems that the problem is related to the host names and IP addresses.

My Drupal site is set up as a virtual host on a machine with a bunch of other Apache web sites. The IP address resolves to a host name that is different from the name of the Drupal site. So even though I had the Drupal site name listed with full permission in the ZoneAlarm settings, it didn't work.

I had to add the actual host name of the machine to the permitted sites in Zone Alarm. Now I can log in to my Drupal site with no problem.

karen.03’s picture

EXact same with IE 6 and Firefox with CA Personal Firewall enabled.
Disable, and I'm in

kdebaas’s picture

Server:
IIS 5, mysql client api 5.0.22, PHP 5.1.6.

Using browsers: Firefox 2 and IE 6 on Windows XP
However, experience same problem using Firefox on Ubuntu Linux.
Clearing history / cookies / cache does not help.

I will paste below some excerpts of my past soliloquy:

At www.parallelports.org/dev I have Drupal 5.1 running on IIS 5, PHP 5.1.6, MySQL database 4.1.21, no MySQLi support. Also, incidentally, no support for sending emails from the server as yet.

I can't get past the login stage, when I click submit after supplying name and password.

When I check out the sessions table in PHPMyAdmin, I see that a session is actually registered, with uid=1. However, the session of uid=0 is also still in the table, and it has a timestamp that is always equal to, or later than the timestamp of uid=1. In fact, its timestamp gets updated, every time I try to login, and the list of authenticated session just grows (in the sessions table), while the anonymous session remains the newest (or youngest). The PHPSESSID cookie that is set in my browser (FF, but in IE same problem) is the one containing the sid of the anonymous user, (that is: uid=0). It does not get updated.

samo’s picture

I had the same problems 1/2 a year ago with iis 5 and php 5.1.2 / CGI.

I isolated the problem to session_regenerate_id().

session_regenerate_id() was not writing the new session id to the client using IIS 5 / CGI + PHP 5.1.2. None of the fixes above (fixCookieVars(), narrowing cookie scope, changing cookie name) solved the issue. The only fixes that worked were removing the session_regenerate_id() call in user.module (security degradation) or changing IIS to use ISAPI instead of CGI.

chx’s picture

Can you do a comparison of the HTTP headers sent if run in ISAPI mode versus CGI?
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

kdebaas’s picture

I can confirm that removing the session_regenerate_id() call in user.module enables me to login.

I don't have the privileges to run the server in isapi mode. Here are the headers from the IIS 5 server running in CGI. The first set is returned on a pageload of the frontpage, after clearing cookies. The second is after submitting login:

Request Headers
Host: www.parallelports.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.parallelports.org/dev/index.php?q=node
Cache-Control: max-age=0

Response headers
Server: Microsoft-IIS/5.0
Date: Tue, 06 Feb 2007 11:10:23 GMT
Connection: close
X-Powered-By: PHP/5.1.6
Set-Cookie: parallelportsorg=fnhqvcalr2q8d1e5tkanunja91; expires=Thu, 01 Mar 2007 14:43:43 GMT; path=/; domain=.parallelports.org
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Tue, 06 Feb 2007 11:10:23 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: text/html; charset=utf-8

And after submitting login:

Request Headers
Host: www.parallelports.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.parallelports.org/dev/index.php?q=node
Cookie: parallelportsorg=fnhqvcalr2q8d1e5tkanunja91

Response headers
Server: Microsoft-IIS/5.0
Date: Tue, 06 Feb 2007 11:11:47 GMT
Connection: close
X-Powered-By: PHP/5.1.6
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Tue, 06 Feb 2007 11:11:47 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: text/html; charset=utf-8

kdebaas’s picture

Commenting out the three Cache-Control lines does not enable me to login. Comparing the http headers with the ones from a drupal site I have installed at home on a LAMP server shows the following difference:
Connection: close in the IIS response, and Connection: Keep-Alive in the Apache/2.0.55 response.

In addition, on the web page from the IIS server, I receive a PHP Notice (whether or not the Cache-Control lines are commented out):
PHP Notice: Undefined index: QUERY_STRING in D:\content\websites\parallelports.org\dev\includes\bootstrap.inc on line 605

gordyhulten’s picture

Commenting out the three lines in bootstrap.inc didn't fix the problem for me.

1. What specific browser and OS has the problem? (including Major / Minor version): FireFox 2.0.0.1 and IE7 on WinXP Pro

2. Does another browser on the same OS have the same problem? Yes, IE7.

3. Does the same browser on a different OS have the same problem? You might not be able to check this, but for example if you are on Windows, and trying a Linux Live CD is not a problem for you, then please try. N/A

4. Does the browser have any toolbars/spyware that could be interfering? Firefox Developer, but it's disabled.

5. Does clearing cookies/history/files help? No.

6. Does a browser reinstall help (if the browser is OS-bound then an OS reinstall)? Haven't tried.

7. What other troubleshooting measures have you tried? None.

8. Do you utilize a firewall? Does switching it off help? No.

The problem just started for me this afternoon. I'm on 4.7.6 and I haven't made any sort of configuration changes to the site in more than a week. Refreshing doesn't help either, FWIW.

gordyhulten’s picture

I upgraded to 5.1 this morning, and that seems to have fixed the login problem.

Although upgrading without being logged in (meaning I couldn't switch themes or disable modules prior to upgrading) was harrowing, it seems to have worked OK (knocks on wood).

Ryan Palmer’s picture

This issue has been bugging me as well. At least for me it was only an issue in Firefox(2.0.0.1), not Internet Explorer (7).

I host my sites on Dreamhost, and they recently upgraded php to 5.2, but compiling my own php and using 5.1.6 changes nothing. When trying to log in, the logs show I have successfully logged in, but it takes me right back to the login form.

I tried re-installing Firefox 2, but the same thing happened. BUT, I installed Firefox 1.5.0.9, and the login issue is resolved!!! I noticed that Firefox 2 was a common trait between us all commenting on this post. I suppose downgrading to 1.5.0.9 doesn't do much to help those having trouble logging in under Internet Explorer, but for now this is a temporary fix.

Ryan Palmer’s picture

A bit more info:

1. What specific browser and OS has the problem? (including Major / Minor version): FireFox 2.0.0.1 on WinXP Pro. Firefox 1.5.0.9 works fine!

2. Does another browser on the same OS have the same problem? No, not that I know of.

3. Does the same browser on a different OS have the same problem? You might not be able to check this, but for example if you are on Windows, and trying a Linux Live CD is not a problem for you, then please try. N/A

4. Does the browser have any toolbars/spyware that could be interfering? Firefox Developer, but it's disabled.

5. Does clearing cookies/history/files help? No.

6. Does a browser reinstall help (if the browser is OS-bound then an OS reinstall)? Reinstalling Firefox 2.0.0.1 does not help. Installing Firefox 1.5.0.9 does fix the problem!

7. What other troubleshooting measures have you tried? Downgrading to php 5.1.6, upgrading drupal.

8. Do you utilize a firewall? Does switching it off help? Forgot to try that. But nothing has changed on the firewall lately... and I get this issue on my laptop from various internet connections.