Nice smooth install.
Fixed the magic_quotes_gpc setting.
Database looks fine.
Created my first account.
Got the email delivery.
Tried to login... No error, but no login. I just end up back at the login page. I've checked my database, and the accounts are in there. I've tried resetting passwords - no help. I've tried to fail login - I get the failure message, so that's working.

My vague guess is that there is some kind of problem with the session, but I can't imagine what it is. I'm no php expert.

Any advice appreciated.

For a demo of the problem, feel free to hit



Steven’s picture

Is your browser set to deny cookies? That could be it. If something had gone wrong at the user login (invalid username/password) you would've gotten an error message about it.

kwerle’s picture

That isn't it (I don't think). For example, I can log into just fine.

autoshop1’s picture

where is the log in thing for myspace, i cnt find it?

autoshop1’s picture

where is the log in thing for myspace, i cnt find it?

jmorrison1970’s picture

In addition to checking for cookie acceptance - you may want to take a look at the system time on the server. I was beating myself up over this same issue for 2 days. Firefox could log in - IE could not. Finally, for reasons unknown, I checked the system time on the server and it was set to 5 years in the past.

It seems that Firefox wasn't checking for the timestamp and IE was. Since the server was issuing a cookie for 2002, IE saw the session as expired and immediataly logged me back out.

I updated the time on the server and all is well.

dshort’s picture

Thanks a lot and I solved my problem with your suggestion.

johnchalekson’s picture

$GLOBALS['tempUser'] = $user;



Oceria’s picture

Indeed this is what helped me out on an ageing drupal 4.6.11 install. Mind you: I still get an occasional return to the login page again, but at least it is workable now.
Time to upgrade to 5.1.


A freshly built testsite with Drupal 5.1 and a new database started to behave the same way as my ageing 4.6 install

This is on a server with php version 5.2.0, zend engine v2.2.0, on apache 2.x (version not given).

Oceria doesn't know where this -repeatbutton -repeatbutton is....

daniel read’s picture

...on Drupal 4.7, with persistent login problems as described by the original poster. Glad it worked for other people, though.

infinity003’s picture

Can anyone comment on exactly why this is the case? This fixed worked for me (Drupal 5.1 and PHP 5.2), but it would be nice to understand why this problem exists...

Note I can log in with Safari but could not with Firefox. With this fix, I was able to log in with both.

Also, what are the security implications of this fix?

cgjohnson’s picture

I too am having this problem; it has been working fine for weeks, and today I created a new user with special role (admin) slightly more limited than user 1. When I tried to login using this info, I get the site maintenance page (I've got my site offline) and cannot login.

No error message, nothing. Can't get login screen to login as first user again does nothing.
I'm on a mac os x using firefox 2.0
drupal 4.7

I tried:
1. clear cache, clear cookies, clear privacy, restart Firefox
2. add to settings.php
ini_set('session.cookie_domain', 'exampleorg');

ini_set('session.auto_start', 0); no avail.

Can someone help me? many MANY thanks. this is a bummer, otherwise my first experience creating (but not administering) a drupal website was grand till now.

cgjohnson’s picture

thanks for this, but it didn't do it for me... any other advice? see my query below

kweisblatt’s picture

This issue seems to be the cause of hosts updating to PHP 5

This one code seemed to work fine with my sites to get it working, but if it dosen't work for others, you may want to try this patch:
Current projects:

evilluke’s picture

Thanks a million John. That would have taken me a year to figure out.

I did some more digging and it turns out my ISP had upgraded from PHP 4 to 5 over the weekend .... and hadn't told anyone ?!

dawalama’s picture

Thanks a lot. Your solution worked for Drupal 5.1 and php 5.1

arturro’s picture

drupal 5.1
PHP Version 5.2.0-8+etch1

best regards

sumware’s picture

$GLOBALS['tempUser'] = $user; appears to have fixed a bunch of problems for me. Thanks for posting it.


Hipfox’s picture

Well done! that solved my login problem.

Drupal 4.7.3 + Apache 2.0 + PHP 5.2.1

$global['tempUser'] = $user;

thanks for this.

kriskhaira’s picture

Worked for me too.

Drupal 4.7.3
PHP 5.2.5
Apache 1.0

rodolfoancheta’s picture

it didnt works to me... im using the 5.1 and nothing....

Spinuzzi’s picture

Hey, there are apparently different things causing this problem for different users - or the variables are very different in different cases. I traced MY problem [5.1 on 5.2.1] to cookies and my firewall (see my post at:, though I haven't solved it completely to my satisfaction yet - so I will keep reading! BTW - arturro ( seems to have found the same thing.

christos5569’s picture

Wasted as well 6 six hours until I can across this comment.
Web hosting company decided to upgrade to PHP5.2 without warning us, and then the admin login stopped functioning.
Searching around, I found a hack on the user.module with session_regenerate_id() but within the user_authenticate() function but that failed.
Then found in the handbook, issues between Drupal 4.7.4 and PHP 5.2 so I decided to upgrade to 4.7.5, but that failed as well.
And finally to this post. Uploaded everything back to 4.7.4 version and modified the index page and everything worked.
If any one else across the same issue follow these instructions - they are the easiest and least time consuming, before you try any of the others options.

Cynscreations’s picture

I am the super administrator and this fix worked, only after I requested a new password.
When I reset the password however, I can no longer get back to the administrator menu,
and the temp password is only good for one login for one day.

It would be ridiculous to keep requesting a new password every time I need to login to the admin
menu and this is not going to be acceptable to my client either.

How can this be fixed permanently????


ipwa’s picture



ipwa’s picture

This fix was working fine until now, it stopped for working for me. Has this happened to anyone else with this problem??



Oceria’s picture

Drupal 5.2 and 5.3 give me a lot less trouble than 4.6 did. Did you recently change the theme of your site? You only change the template of the theme you are using. If you start using an other template (or created your own) you should reapply the patch to the new template. Hope that helps!

Oceria doesn't know where this -repeatbutton -repeatbutton is....

ipwa’s picture

I didn't apply the patch I just added the code for the index.php, which is not part of th theme. Thanks.



santino’s picture

Thanks a lot, johnchalekson :)

tyswan’s picture

I accidentally stumbled across this post. I didn't even know the question to ask, but this did the trick for me too!

Thanks again.



BLUE MOUNTAINS health & harmony

building an alternative health & spirituality community in the Blue Mountains

alienzed’s picture

I am really starting to like this whole drupal whole, the community aspect is irreplaceable.

Treesong’s picture

I recently upgraded my hosting account from PHP 4 to PHP 5. I was able to log in, but any time I clicked on any link, I was "anonymous" again. This bit of code fixed the problem. My index.php already had drupal_page_footer(); but did not have $GLOBALS['tempUser'] = $user; and that is what fixed it.

kriskhaira’s picture

PHP 5.2 or 5.3? Drupal modules aren't very happy with 5.3.

gopiraj_m’s picture

This fix saved my day.
Had the same issue during my login. I could log into my site only on Firefox but not on chrome. Don't know if its the Over-caching in chrome. But this worked.

jxs2151’s picture

Are you trying to login with the first account you created? This is the admin account by default and is identified with uid=1 in the users table.

Once you login with this account, go to Home » administer » accounts » Permissions and check the box for authenticated users for "Access Content"


kwerle’s picture

Once you login with this account, go to Home » administer » accounts » Permissions and check the box for authenticated users for "Access Content"

Every time I try to login with ANY account (including the first one), I end up back at the login page. I have no interesting (admin) links. Just the login page.

Again, feel free to hit my site and see what happens.

Steven’s picture

Take a look at the contents of the watchdog table in your database, it contains all events that happen in Drupal.

kwerle’s picture

You, too, can now see what drupal recorded (as of now):

Pretty clear it thinks I'm logging in. And yet my client isn't getting anywhere...

Damn it. <a> doesn't do what I thought, and the tips don't say how to embed a url easily. Time to submit another bug.

jxs2151’s picture

Can you create a new user and login as that user? If you can, change the uid for that user to 1 in the users table. That user then becomes your first user and has admin rights be default. Use this login instead of the first one you created.

I had to do this on the first drupal site I created. Don't know why, don't care anymore- it worked.


kwerle’s picture

Every time I try to login with ANY account (including the first one), I end up back at the login page. I have no interesting (admin) links. Just the login page.

nisguy’s picture

It's a cookies thing. If I login with an admin account and change something, then login with a test account with different permissions there is often a cookie conflict and I have to delete the cookie. Now what I do is log in to test on one browser (IE) and log in to change things with another browser (FF)

ProgressiveBastion’s picture

Thanxs jxs2151

I thought that would work since I was able to create a new account. I changed the new account to user 1 my broken one to the user name, then I went into and altered the info on old user (broken one) just enough so I could recreate new user same as the old user minus the slight edits. After editing the broken user account I had to save it, then I was able to do the recreate... Then I went into my account setting and turned off blocks etc. and configured those options in my edit
page same as the old broken account. Viola! A 12 minute fix tops. Just took 2 days to get to it.

Thanxs again brother
peace Michael S.

Yup, I'm Liberal...

lib~er~al (lbr-l, lbrl), adj.

1a. Not limited to or by established, traditional, orthodox, or authoritarian attitudes, views or dogmas; free of bigotry.

b. Favoring proposals for reform, open to new ideas and beha

mkogel’s picture

I have created two new users and tested their rights and so on. Everything worked fine until I tried to login as admin (the very first user I created at the time of installation) it did not work. It gave me an error of "unrecognized username/passord". I know my user name and password were admin/admin but did not take it.

So, this trick worked for me. I changed one of the new user's UID to 1 and now can login again with full admin rights. It is a pain however if I need to do this everytime I do a user testing.

I am a newbie, please be gentle with me...

I am not a developer so I need idiots guide sometimes

Dan G’s picture

I'm having the same problem, and it appears kwerle never found the solution, as the address he gave above now says it's powered by XOOPS.

I've been using Drupal for about two weeks, was able to sign in and out without difficulty. Now, any attempt to log in, simply returns you to the login page. Any attempt to create a new account, returns you to the account creation page, and does not actually create a new account.

Tiwahe’s picture

Well...guess its not just me...I'm having the same prob...any news on a fix? Or...should I just reinstall?’s picture

I'm getting the same problem. Is it related to my Apache or PHP settings I wonder. What are the recommended Apache 2 settings for Drupal?

leemag’s picture

I've had the same problem. I've messed with the database, reinstalled it several times, all so no avail. Any *valid* login just returns to the login page. An invalid login gives the usual error. Works the same with IE and Mozilla. I surely would like to have a clue about what to do now.

feetstink’s picture

I had some users of IE who had this problem, i think. if you go to tools > internet options... then to the privacy tab. click on Advanced... then override automatic cookie handling, accept first-party cookies and always allow session cookies. this worked for them.
i have one person who can't login from linux/firefox, but i haven't figured out why yet. i use firefox on windows at work and it works fine, so any ideas on how to fix it for him would be nice.

leemag’s picture

Thanks, but those were already set on IE. I'm allowing all cookies on Mozilla. Doesn't seem to me that the browser would be the problem if it doesn't work in either.

But wait! I found the problem - turned off Zone Alarm. Works fine now.

gunner’s picture

crazy, but I turned off ad blocking, and it allows me to log in... it won't otherwise

shimshun’s picture

Thanks for this i had a lot of problem getting drupal going after first account created and turning off zone alram worked. Now why is that?

Parkasaurus’s picture

Hi. Where is "zone alarm" located?

I'm having the same problem...

grabur’s picture

Zone alarm is firewall software.

I have just experienced the same problem in 4.7 after moving my site to a new server.
However I can get back in through an email password one off login. But not the normal login, arrggggh.

ReFuser’s picture

It looks like drupal redirects us to its login/home page every time it can't set its cookies as well.
By turnning on Zone Alarm's Privacy Advisor we can see if ZA is blocking cookies from a particular site (localhost in my case).
To enable ZA's Privacy Advisor goes to privacy > main > (cookie control) custom > cookies . Toggle it on at the bottom.
Load the drupal home page again and you will (i did) see the privacy advisor showing up that the cookies were blocked.
To get ZA accepting drupal's cookies, i just reset everything on Custom Privacy Settings to their default values.
This might help something!

jivyb’s picture

Never would have figured out how to get Zone Alarm to stop interfering with Drupal

pelikan2402’s picture

problem: Access denied on LOGIN.

Two ways to solve problem:
#1: One way is to Turn off Zone Alarm.

#2:Or go under Privacy in ZA. in the Cookie control field click on custom. Go to Ad Blocking tab. Uncheck Popup/pop-under and Animation box. Apply. restart server few times if it doesent affect right away.

Worked for me.


Paul Iliano’s picture

Thanks! Overriding automatic cookie handling and then checking "Always allow session cookies" did indeed solve my problem of not being able to login.

jgestiot’s picture

Thanks for the tip, it fixed my problem. IE7 is particularly aggressive with anything security. I guess it will cost many big sites a lot of money to get MS to add them into the list of friendly sites (i.e. sites that do not cause massive security warning on people's IE7) ;)


wedge’s picture

I think I'm having the exact same problem (I'm also not able to log on after a fresh installation). To me it looks like it's a problem with running Drupal with PHP as FastCGI on IIS. When I try to run Drupal with PHP as an ISAPI module it works fine. Can anyone figure out why it's behaving like this? I'm stumped.

FastCGI is used for instance when you install the EasyWindows Installer from


bluedropstudios’s picture

I've had this same problem, as it looks like a lot of people have had.

If you are using clean URLs, make sure you have mod_rewrite turned on in Apache. In Debian (>=sarge) under Apache 2, you must link mod_rewrite from /etc/apache2/mods-available to /etc/apache2/mods-enabled. Other versions of Apache 1.3/2.0 require you to have the line uncommented to load the module.

Jeremy - the linux web guy

Joe Murray’s picture

I'm using Debian GNU/Linux. In my /etc/apache2/mods-available directory I have a rewrite.load but not a rewrite.conf file or mod_rewrite

Also, I have the problem even though the rewrite load file is symbolically linked to the /etc/apache2/mods-enabled directory.

Am I missing something?

Joe Murray


Jones’s picture

On the "register" page, I can't even get my first account email sent off; it just blanks the fields and reloads the page. No error messages or anything. I set up an account at and was able to log in just fine. Maybe my problem is that stuff with Apache. How exactly do I go about changing those settings? (I use a hosting company, so the server isn't in my possession.)

The site is at `` if you want to check it out. Feel free to try and set up the first account. But if it works, um, I'm gonna want the password. Please help! I'm itching to get rolling on my site.

khaki’s picture

weird! i was able to login with your site by creating an account...

axel’s picture

Site works and logins works. One day I logout then try login back. And no more success - no error about bad username or password, site returns back to user/login page without any messages, user stil unlogged. And no any new strings in watchdog :\ - attempt not registered by site. Not only me can't entry - other users too, all from different browsers (FireFox, IE). Clean urls disabled, site placed under subdirectory of virtual domain, Drupal 4.5.1 installed.

Russian Drupal Community

axel’s picture

I search and found some similar reports from different Drupal versions: (Drupal 4.2.0)

Russian Drupal Community’s picture

axel’s picture

Enabling of 'clean urls' solve problem.

Russian Drupal Community

multiplex’s picture

I have no idea why this is happening I have set up Drupal a lot of times before but this is the first time i'm doing it on a webhost instead of dedicated server.
Can't create any user or login, even changed tables and created user and then tried to log in... it does show up in the 'online users' block but don't get any links or admin options! If anyone has a clue, i've enabled clean urls and still the same problem!

--- MultipleX
Don't click this link if you don't know Farsi!

multiplex’s picture

I added print_r($_REQUEST) on the index.php page so it should show if it picks up the value's from the form, and it seems this isn't happening!
Could this be it? And if so, does it have something to do with any PHP settings or variables?

Also could it be I have to change/edit something in the '.htaccess' file??
Cause I get an error from the server when I upload the standard '.htaccess' that comes with Drupal so I had to comment out a few lines!

Any help very much appreciated!
--- MultipleX
Don't click this link if you don't know Farsi!

maxm’s picture

I had the login (non)redirect problem, and enabling clean urls (with mod_rewrite) fixed it.

transistor’s picture

Just installed Drupal in my Mac, OS X 10.3.7 using Safari and FireFox (both accepting cookies) and I have the same problem. After creating the first user, I can't login and I don't get any errors.
If I use a wrong login, I do get the appropiate error msg.
Now what?

fleed’s picture

Same thing here. Old drupal site works no more. Brand new install on the same server works fine! I can't spot the difference, other than the code base.

fleed’s picture

Could this problem be related to sessions? I have problems when running under suphp on a brand new install of drupal. The reason for that is the php settings in .htaccess which are not valid for suphp. To properly fix it I'd have to put those settings on a php.ini file specific for that vhost. Instead I disabled suphp for that specific vhost. But I still have the problem with an old install as I had previously. It's the same with plain mod_php or suphp... this is weird.

bigeye’s picture

identical same problem:

Use valid user/passwd, kicked back to login page.
Use invalid user/passwd, kicked back to login page and saying Access denied.

It appears that the first case is passed the login check, for some reason, it cannot redirect to the correct page or the login info is not stored.

It doesn't work with both IE and FireFox. We can see there is a cookie there in FirFox. So it's not the cookie problem also.

BTW: I am using MySQL with UTF8 charset. Wondering if it's this problem.


bigeye’s picture

In settings.php add this satement:

ini_set('register_long_arrays', 1);

or modify this in php.ini globally:

register_long_arrays = On

(the default is off)

It works !!!!!!!

cmo’s picture

Didn't fix it here. My problem is only related to IE though. Login works perfectly in Mozilla Firefox, but it does as described above when trying to log in with IE.

archetwist’s picture

I had problems logging in under Firefox (no problems under Opera) and your tip fixed the issue. Thanks.

bigeye’s picture

Please add this line to settings.php as well:
ini_set('session.cookie_domain', 'domainname');

domainname here is the domain name used for your drupal URL. No subfolder, No http://

Try it.

Yours is different though. Mine is the server side setting problem. For both IE and Firefox. Yours appears to be the client side browser issue.

neuromage’s picture

I had the same problem as well. I could login with no problems, and then one fine day, it stopped working. I tried all the solutions listed on this page but none worked. In the end, I found out that my sessions table was corrupted. I tried repairing it, but both my .myi and .frm files were corrupted, so in the end, I had to recreate the table. Just want to point out that this is one of many potential solutions to the problem in this thread.

littleprince’s picture

I have the exact same problem
Using the correct password for any account returns the same page.
Using wrong passwords returns page with the wrong username/password thing.

I'm on Windows XP SP2, Apache 2.0, the latest mySQL, PHP, and Drupal.

This has become so frustrating I'm ready to go back to Xoops.

littleprince’s picture


Go to your php.ini file
Find this line
session.cookie_path = \

Change it to session.cookie_path = /

Does anyone know why php is distributed in such a way? I realized when combing through cookies stored from my test site vs

Hope this helps other ppl.

f1shnch1ps’s picture

Thank you thank you thank you.

I have been wrestling with this access denied problem for 3 days - tried every combination of suggestions in thisd forum.... and this one small change was the difference. Please try it everyone

I am on WINXP, Apache 2.0, php 5.2 and drupal 5.1

mikeschinkel’s picture

Where is php.ini on a shared Linux server?

drupalisme’s picture

I' using shared hosting on and I just put the php.ini in public_html/ and it's works!

sobi3ch’s picture

# find /etc /usr -name php.ini -type f
Look for php.ini (type = file) under /etc and /usr folders.

tdway’s picture

Thanks littleprince! I'd almost given up. This worked for me. FYI here is my setup:

Drupal 5.2
Windows Server 2003
Apache 2.2
PHP 5.2.1
MySQL 5.0.27-community-nt

Anyone know if this is a Windows only issue?

zondor’s picture

for me it was browser related because i can login to my Drupal site or this Drupal site using Opera instead of Internet Explorer in this computer lab. however, using this IE i can login to other sites including gmail and wikipedia but not drupal. i wonder why is that - something for drupal to be fixed.

iokevins’s picture

I disabled the login block, and I could no longer log-in via user/login using Firefox 1.5. :o

I logged in via IE, and re-enabled the login block, and now I can log-in via Firefox 1.5. :o

I did notice that when I click on request new password, it says "access denied." :? I must have something messed up, but I do not know what.

"Extraordinary claims require extraordinary evidence"
-- Carl Sagan

iokevins’s picture

Clearing all of my private data in Firefox 1.5 fixed this issue.

"Extraordinary claims require extraordinary evidence"
-- Carl Sagan

jmcclare’s picture

I was having this problem and I tried every solution listed in this discussion and the discussions in each of the duplicate bug reports. None of them worked for me. After a long process of tracing the program flow (PHP really needs a debugger), I found out what my problem was and I have a hack to fix it.

For reference, I am running drupal 4.7 on apache 1.3 under debian Linux 3.1 with MySQL5. This also means that I am using the mysqli api to connect to the database, and I have the file I found in another discussion here.

My problem was that the sessions table was not being written to. The problem was that for some reason, the number of affected rows was coming up blank after a certain number of queries. I was echoing the all of this info to the screen from within the db_query function. What I did to fix this is a hack, but it works. I basically made drupal make a new database connection after every five queries.

in includes/, I changed:

function db_set_active($name = 'default') {
  global $db_url, $db_type, $active_db;
  static $db_conns;


function db_set_active($name = 'default') {
  global $db_url, $db_type, $active_db;
  static $db_conns;
  //debugging. reset connection after a certain number of queries
  static $connections;
  if ($connections > 5) {
  	static $connections = 0;
  	$db_conns[$name] = NULL;


function db_query($query) {


function db_query($query) {
  // debugging. call db_set_active each time to give it a chance to
  // count the queries and reconnect after a specified number. 

This could be yet another fix that only works for people with my particular flavour of the problem, but hopefully that's you and you will be able to paste this code in and move on instead of spending three solid days hacking at it like I did. If this doesn't work for you, make sure you try the other possible solutions listed in this thread, and in the other discussion

twasserman’s picture

I installed Drupal 4.6.5 on my local Windoze box using the versions of Apache, PHP, and MySQL that are part of the "Sugar on Spike" stack from SugarCRM. The Drupal page comes up fine and prompts me to create the first account, which I do. It then displays a password for that user name (uid=1). When I go to log in with that user/password combination, I get the error message "Sorry. Unrecognized username or password. Have you forgotten your password." So I checked a bunch of things. I made sure that the localhost site would accept cookies. I turned off ZoneAlarm even though it shouldn't be an issue on a local machine. I looked at the users table in the MySQL database name to make sure that the uid=1 entry was there. I looked at the users_roles table to make sure that uid=1 was represented there. Everything good so far.

I browsed the watchdog table. Line 4 is the access denied entry mentioned above. Subsequent failed logins also. So I took matters into my own hands and wrote a SQL command to change my password in the users table following the suggestion of (see

update users set pass=MD5('newpwd') where uid='1';

Now I'm able to log in and administer the site.

But it appears that drupal stores a different value in the database than the one displayed on the screen. My only guess is that this is a case of the OLD_PASSWORD problem with mySQL, but it would be helpful if someone took a look at this issue.


cgharris’s picture

I have a number of Drupal sites running 4.6 with no problems. When I try to create a new site with 4.7 I get the login issue. Running on Windows 2000 with IIS PHP is 4.3.1 and mysql is 4.0.22. All my my established 4.6 sites are running fine, but any new 4.7 sites I try to add I get this login problem. I have tried all of the different suggestions here and elsewhere, but nothing is working.

Any other suggestions or any additonal information I can provide? Thanks!

ckclarke’s picture

Was able to log in using Firefox and then suddenly not IE, but then also found that using IE on another machine with an identical setup got me in.

The Drupal log showed the IE session opening even when the login appeared to 'not take'. (I'd get the login page back again, no error messages).

So, I used phpinfo() to find out what cookies were being sent and found that my IE had somehow picked up two seperate PHPSESSID cookies for my Drupal site, and was sending both. PHP was only recognising the older of the two cookie values, hence it was not reconnecting the new, logged-in session.

Once I cleared all the cookies in IE, it logged in fine.

I'm going to make a guess that the same double-cookie thing has happened to Drupalites who've had sudden problems with Firefox or other browsers.

SO: Somewhere in Drupal there must be a page which is sending the double cookie. Where I don't know... please could everyone work to hunt down this little easter egg?

Also, IE does not regcongise the cookie as a session cookie, because the expiry is set to a week or so. If the cookies did expire immediately, the double cookie would go away once the browser was closed and re-opened.

I'm currently using 4.7 RC3, with the following modules:

Amazon Tools
Service Links


Terry.Monnett’s picture

After two days of reinstalls, deleting tables, attempting hacks in related threads, I finally was able to login as admin using both Firefox and Safari (Mac OS 10.4.6) after deleting all PHPSESSID cookies.

My attempts to login after creating the first user (as well as other users) was the popular return to the login page with a valid login and the normal error message with an invalid login. Additionally, attempting to go directly to
http://DOMAIN/?q=user/1/edit would give an access denied message.

I'm not sure how to avoid a reoccurence (expiraton of cookies, perhaps?), but can at least offer this as a possible solution for now.

(versions not in my control)

cgharris’s picture

If I run it under Apache, no problem. IIS and I get the login issue. Obviously I just need to switch to Apache, which I am working on...

ckclarke’s picture

Bearzilla’s picture

Had the same problem running on Apache 2, PHP 5.0.4, Drupal 4.6.5 and 4.6.5, Fedora Core 4.

I tracked it down to the session_set_save_handler function in includes/ failing. If this doesn't work, Drupal's session handlers don't work and it won't update the sessions table in the database so it thinks you're not logged in.

For this function to work, the PHP setting session.save_handler must be set to "user". Drupal tries to do this in the sites/default/settings.php file, but in my case it was failing and the following messages appeared in Apache's error log:

PHP Notice:  A session had already been started - ignoring session_start() in .../drupal-4.6.5/includes/ on line 14,
PHP Warning:  ini_set() [<a href='function.ini-set'>function.ini-set</a>]: A session is active. You cannot change the session module's ini settings at this time. in .../drupal-4.6.5/sites/default/settings.php on line 109

Basically, session.save_handler must be set before any session starts. However, the default PHP install had the line "session.auto_start = 1" in the php.ini file so PHP was automatially starting a session before Drupal had a chance to change the settings.

The fix was easy: change php.ini so that the line reads "session.auto_start = 0" and it Drupal now works!

It's be good if Drupal could detect this situation and handle it, or at least report a meaningful error.

skcombs’s picture

Could this explain why I see the following behavior (Drupal 4.7.0, Apache version 1.3.36(Unix)
PHP version 4.4.1, MySQL version 4.0.27-standard):
When I login to my Drupal site, 4 sessions show up in the sessions table; the UID for the first 3 sessions are 0, the 4th one is the correct UID. Then 3 more sessions are created with UID of 0. What is going on? THe login fails, although the log file written by watchdog shows that a session was started for the correct user name.

The server is 4 hours fast. Could that have an adverse effect?

skcombs’s picture

In settings.php I added set_ini('session.auto_start', 0);
That seems to have solved my problem. (I don't have access to php.ini)
Until I made that change, I was seeing as many as seven sessions started for one attempted login. This no longer happens. Thanks so much.

squaretone’s picture

session.auto_start = 0 worked for me when I updated the php.ini file.
I now have sessions being written again.

my host did a major php/mysql upgrade and it affected quite a few things. This saved me.

Eric Lawrence
Developer/UX Designer

alkhulaifi’s picture

I have tried all the listed solutions and still i can not login with IE (6 and 7) but i can with firefox. I think this problem is related to the hosting enviroment. I facing this issue with a linux box with CentOS 4.3. I have a secound box with linux CentOS 4.2 and it is working perfeclty !!

also this issue happen for 4.6 and 4.7 ?!

If you like to try visit:

legacyb4’s picture

I'm encountering the same problem on a 4.6.6 fresh install on a Linux box server where and older install of 4.6.3 works smoothly.

Log in brings me back to the log in page without any obvious errors in Watchdog or Apache logs.

Hope this can be solved soon.

ff1’s picture

I am in exactly the same position as legacyb4. New install of 4.6.6 fails, but older install of 4.6.3 works perfectly.

I get 'Session opened for username' followed by 'user/1/edit denied access' in the watchdog table.

Really need some help with this one.

dan.thompson’s picture

I'm having the same issue here. Never had this problem with Drupal 4.6.X, but am tryng to get Drupal 4.7.0 RC4up and running on a test machine, and am having this same problem. I hve tried everything above, to no avail.

Windows XP Pro SP2
Apache 2.0
PHP 4.3
MySQL 4.1

Perhaps 4.7 is not yet ready for primetime on all systems. I'm going to go try it on my Linux host, and see if I have the same issue there.

Acert93’s picture

This is really odd. All my other Drupal accounts work (most are 4.6.5). I setup a new account last night and tried to login with IE6 (Windows XP) this morning and a no go. Tried FireFox and it worked fine. Drupal 4.6.6 here as well (PHP 4.3.2 I believe).

EDIT: I uploaded 4.6.5's user.module. If I run into problems I will update here.

alhearn’s picture

I had the same problem: login attempts simply returned me to the login screen, even though I was actually logged in. Even though the problem existed on one of my Windows computers, it worked fine on another identical computer on the same desk.

Based on suggestions in another thread (can't remember which one), the following solved my problem. Replaced my 4.6.6 modules/user.module file with the 4.6.5 version.

I'm not totally confident that this permanently solves the problem since the problem is so strange. It's definitely related to sessions and involves some combination of host/client elements. If someone smarter that me could look at user.module and determine what changed between 4.6.5 and 4.6.6, it might lead to a real solution. I'm not saying that 4.6.5 worked for all cases, but whatever changed between the two version relates to the problem.

Sam Moore’s picture

As per another user's post, i deleted all cookies and the problem went away (for now).
I was noticing that, even though I couldn't get past the login screen, Drupal was reporting that I was among the logged-in users - so obviously there's some sort of session weirdness going on here.

Now if I could just figure out how to stop this from happening again...

Server: linux (freevps); Apache 2.0.46; PHP 4.3.2; mysql 3.23.58; Drupal 4.7 (had the same problem with the RC i was using)
Client: macOSX, Safari & Firefox

desiprem2003’s picture

I am having the same problem. Creating first accout, going back to login and it does not work. I tried installing so many times and tried all the tricks above but no success. Is there a simple solution because this should be a simple fix with the new release and thats what I have.

Can some one post step by step procedure and list complete solution since this is hapen to many installers?

quineto’s picture


don´t know what to do I´ve tried with all the suggested fixes but none of them work

we need no find a fix soon its getting on my nerves althogh I now drupal is great and we are goint to find a solution soon.

acidcortex’s picture

PHP 4.3.2 and lower versions use PCRE (Perl Compatible RegEx) older than drupal requires and if u have clean_urls turned on watchdog will mark u as if u logged in, but u will stay on the login page

just upgrade PHP to version higher then 4.3.2
worked fine 4 me


cgharris’s picture

Tried again with 4.7.0. Tried all of the other things suggested since last time. Still running on IIS.

When I first hit the page, I get a new record in the sessions table. UID of 0 with a SessionID of 56 (shortened for space). Then I enter the username and password. Now there is a second record in the sessions table with a UID of 2 and a SID of 44. But when I look at the cookie on my computer, it is for a PHPSESSID of 56...

Is that the source of all these problems? The cookie left on my computer connects me as a user 0? Any other thoughts on a fix?


Sam Moore’s picture

Yeah it sure looks like you get a "Guest" PHPSESSID cookie when you first get to the page, before login - somehow this isn't being replaced by the proper authenticated-session cookie after you log in.
Anybody know where these cookies are set?

By the way I'm running Apache under linux, so I don't think this is a server thing - others are having the same trouble under IIS.

sculder’s picture

I wonder, if developers look through the hottest topics, at least sometimes :)

Heine’s picture

you filed a bug report ;-)
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.

sculder’s picture

I was surprised, nobody had done it earlier.

RobRoy’s picture

Clearing cookies was the problem for me since it worked in Firefox but not IE.

I think this issue may have something to do with it.

Some of my Drupal sites:
Quotes | MySpace Layouts

quineto’s picture

Ok, EUREKA !!! :D

I applied this recomended solution and it worked for me I think is not the best solution but it works. So I am going to use it until I find a better one. For the fix, you have to modify the user.module in your module files and comment the next three lines:

FROM this:

$old_session_id = session_id();
db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

TO this:

//$old_session_id = session_id();
//db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

And That´s it

I am Using:
PHP 4.3

Sam Moore’s picture

Thanks, quineto - that worked!

Drupal 4.7
PHP 4.3
Safari and Firefox

sculder’s picture

Damn, seems that's not a universal solution.

senixon’s picture

I have tried all the proposed solutions up until this post w/o success, but this one did the trick for me!

My Setup
Drupal version 4.7
Windows 2000 Server


mountain girl’s picture

have tried so many fixes without success until now!! thanks!!!

mountain girl’s picture

it did fix the problem in ie but it worked once in firefix and then the problem came back again. ... blow

quineto’s picture

I have tested this fix in firefox, mozilla and IE , it works pretty well in all of them, what version are u in drupal 4.7? is this ur first install?
I found out that is very importatn to upload files in binary format through ftp to ur server to keep the files correct, this save lots of problems difficult to find out, so check this...

please let us know how u are doing with this issue

alias420’s picture

Redhat EL4
Apache 2.0
PHP 4.4.2

Just commenting line #943 worked

943: //session_regenerate_id();

Ryno’s picture

This worked for me. However not all sites will have that line in..well..the same line. It is also important to note that if you're going to attempt this fix, download the user.module from your site (that's already had editing done through the software) rather than trying to edit the default one that comes in the Drupal archive. Yeah...I felt stupid.

Thomas Schürmann’s picture


The problems ar occuring in firefox Mozilla/5.0 , not in ie.

I'm using

PHP Version 5.1.4
xampp for windows
Apache/2.2.2 (Win32)

and after reading all this i tried commenting line 967

// sess_regenerate();

and it seems to work.

Thanks for this thread!

dan.thompson’s picture

The comment out lines solution fixed my problem Using Apache2/PHP4.3 on a Linux host.

deathgod’s picture

see the subject

Paul Armstrong’s picture

many thanks for this

i've got several druapl installs on the same box (all the same codebase, all the same evirnoment) and only my latest setup was giving me the problem.

login with inavlid credentials gave correct error
login with correct credentials just redisplayed log in form!!!
login via request new password was ok and showed the previous "failed" attempt as successful!!!!!!

tried allsorts.

clearing all cookies solved it on firefox but not on IE but fortunately this patch to user.module got things working.

completely baffled, especially as my other "identical" (apart from content) installs were fine.

anyway, thanks again

ibster’s picture

I know that it's like over a year since this problem occurred for most people but my ISP recently upgraded and this has worked for me!

deekayen’s picture

I was just able to reproduce this in IE. I logged in at The significance of that is the $base_url in the settings.php file is set to be, so the site redirected to IE recorded the cookie as deekayen@agencysolutions[1].txt.


The sessions table recorded

uid               sid                  hostname   timestamp   cache  session
 0  61ciq55i7mmuv4vo2j36lb5si00tfimm  68.209.x.x  1146859756    0 	 

That was an ah-ha! moment since there is no uid 0.

Then I saw it also recorded a cookie for in deekayen@www.agencysolutions[1].txt:


The sessions table had the correct UID:

uid               sid                   hostname   timestamp   cache  session
 3   5l3dcgecfsthlkn6pj18au4sn32h8at6  68.209.x.x  1146859756    0      

Note the timestamps are exactly the same. Neither session has a sess_ file in the tmp dir. There are a total of 6 sessions for UID 3 in the DB, and 164 for UID 0.

Now what is IE doing? After logging in, reloading the page on , Ethereal says:

0000   00 d0 9e a2 4b c1 00 0c 76 7d 07 48 08 00 45 00  ....K...v}.H..E.
0010   01 8d 53 a6 40 00 80 06 c2 08 c0 a8 00 05 45 38  ..S.@.........E8
0020   dd d6 0c ad 00 50 3f 84 ba 1b 98 7e 57 68 50 18  .....P?....~WhP.
0030   ff ff ad 08 00 00 47 45 54 20 2f 20 48 54 54 50  ......GET / HTTP
0040   2f 31 2e 31 0d 0a 41 63 63 65 70 74 3a 20 2a 2f  /1.1..Accept: */
0050   2a 0d 0a 41 63 63 65 70 74 2d 4c 61 6e 67 75 61  *..Accept-Langua
0060   67 65 3a 20 65 6e 2d 75 73 0d 0a 41 63 63 65 70  ge: en-us..Accep
0070   74 2d 45 6e 63 6f 64 69 6e 67 3a 20 67 7a 69 70  t-Encoding: gzip
0080   2c 20 64 65 66 6c 61 74 65 0d 0a 55 73 65 72 2d  , deflate..User-
0090   41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 34  Agent: Mozilla/4
00a0   2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b 20  .0 (compatible; 
00b0   4d 53 49 45 20 36 2e 30 3b 20 57 69 6e 64 6f 77  MSIE 6.0; Window
00c0   73 20 4e 54 20 35 2e 31 3b 20 53 56 31 3b 20 2e  s NT 5.1; SV1; .
00d0   4e 45 54 20 43 4c 52 20 31 2e 31 2e 34 33 32 32  NET CLR 1.1.4322
00e0   3b 20 49 6e 66 6f 50 61 74 68 2e 31 3b 20 2e 4e  ; InfoPath.1; .N
00f0   45 54 20 43 4c 52 20 32 2e 30 2e 35 30 37 32 37  ET CLR 2.0.50727
0100   29 0d 0a 48 6f 73 74 3a 20 77 77 77 2e 61 67 65  )..Host: www.age
0110   6e 63 79 73 6f 6c 75 74 69 6f 6e 73 2e 75 73 0d
0120   0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 4b 65 65  .Connection: Kee
0130   70 2d 41 6c 69 76 65 0d 0a 43 6f 6f 6b 69 65 3a  p-Alive..Cookie:
0140   20 53 45 53 53 49 4f 4e 49 44 3d 36 31 63 69 71   SESSIONID=61ciq
0150   35 35 69 37 6d 6d 75 76 34 76 6f 32 6a 33 36 6c  55i7mmuv4vo2j36l
0160   62 35 73 69 30 30 74 66 69 6d 6d 3b 20 53 45 53  b5si00tfimm; SES
0170   53 49 4f 4e 49 44 3d 35 6c 33 64 63 67 65 63 66  SIONID=5l3dcgecf
0180   73 74 68 6c 6b 6e 36 70 6a 31 38 61 75 34 73 6e  sthlkn6pj18au4sn
0190   33 32 68 38 61 74 36 0d 0a 0d 0a                 32h8at6....

Note, IE sends both cookies. The second cookie/SESSIONID is the one with the correct UID.

Then I sniffed a GET for /admin, POSTed a login from the user login block, and saw one cookie change. GET /admin HTTP/1.1 sent the same SESSIONID values as cookies and gave a HTTP/1.1 403 Forbidden (no surpise). The login submission from the block was POST /?destination=admin HTTP/1.1 and send the same cookies which got a HTTP/1.1 302 Not Found reply, only the reply sent back a new cookie which replaced SESSIONID 5l3dcgecfsthlkn6pj18au4sn32h8at6; SESSIONID 61ciq55i7mmuv4vo2j36lb5si00tfimm (UID 0) is unchanged. The 302 location was, so IE sent back a GET /admin HTTP/1.1 with the old UID 0 cookie and the new UID 3 cookie. Drupal still said HTTP/1.1 403 Forbidden.

Naturally, to explain all the problems, the UID 0 cookie has to be taking presidence, so in the bottom of, pasted echo '<!--'. serialize($_SESSION) . serialize($_COOKIE) .'-->';. When I viewed the source, the first line of output was the UID 0 sessionid: a:0:{}a:1:{s:9:"SESSIONID";s:32:"61ciq55i7mmuv4vo2j36lb5si00tfimm";}

Here's the part where fixing becomes painful. If you think you can just delete the UID 0 cookie file deekayen@agencysolutions[1].txt, IE still sends the cookie SESSIONID of UID 0. I did use the IE cookie deletion option in Internet Options to delete the cookies and login worked again. This has not been the case for me in the past - once before I used Internet Options' Delete Cookies option and still couldn't login, but I didn't go through this deep of a process to debug.

To try to prevent this in the future, I've added this to Apache .htaccess

  RewriteCond %{HTTP_HOST} !^ [NC]
  RewriteRule ^/?(.*)$1 [R=permanent,L]
robertgarrigos’s picture

I'm having this same issue of two recorded sessions with same timestamp, second one with a uid = 0. However this solution doesn't apply for me.

I'm having this problem on a windows machine (ISII) running PHP 5.1.2 as fast CGI. So no .htaccess file to modify, no mod_rewrite.

My hosting company - my client's actually. I would never run drupal on a ISII ;-) - switched from php 5.1.1 (which had no problems!) to php 5.1.2. I guess this is just a php related problem/bug with ISII. If I could go back to php 5.1.1 or ahead to 5.1.3 I might track the problem but it's not in my hands. Has anyone come up with something about it?

BTW, changing uid value to 1 in the sessions table solved the problem...until you logout of course :-)
Robert Garrigos
Professional site:
CATdrupal - Catalan Drupal Users Group:

lambert’s picture

Thanks very much for the very clear explanation.

Howerver, now I am having the problem on my own site after installing 4.7.

Like others, I'm amazed that this thread is so long-running.

srcnyc’s picture

I'm not sure I put the echo statement in the right place in my file. I got this error:

warning: Cannot modify header information - headers already sent by (output started at /usr/www/users/srcnyc/drupal/includes/ in /usr/www/users/srcnyc/drupal/includes/ on line 139.

lambert’s picture

Clear your cache; there's a partially sent page in it.

sculder’s picture

Now that I've started checking everything, that could've caused the problem, I've found out one nice thing: Drupal doesn't create any session files in the session.save_path (though it writes the database 'session' table and browser succesfully creates cookies). And it's not php's settings bug, because other programs sucessfully create those files.

Any ideas about that?

theGlooGuy’s picture

Here's the symptoms that we found and our fix.
Our server went down today and we could log in using Firefox but not IE (sound familiar). Read this post and tried everything including clearing the cookies.

Here's what was happening with us. Our server was one hour behind when it came up. So when you visited the drupal site, it would return a guest cookie, when you logged in you were actually authenticated but IE refuses the new cookie because it deems it older than the cookie it has so while you're actually authenticated and logged in, you were working with the 'old' guest cookie after that. All to do with timestamps. Clearing your cookies in your browser won't solve your problem. Firefox apparently isn't as strict about cookie timestamps or maybe it modifies the timestamp with the receive time and not the sent time.

Hope this helps some of you folks, it took a couple of hours of head scratching on our part.

Check your server time!

Chaos_Zeus’s picture

Everything here has not worked, tried sequentially from the top, for me it seemed to be related to the Front_page module. I removed that from the site entirely and it worked. Using the 4.7 version of Front_page, as well as Drupal 4.7.

Jeroen Haan’s picture

I changed the character set from utf-8 to the old iso-8859-1.
Somehow session cookies are sent now to the clients RAM and on the server no extra session files created and thereby the session remembers your session_id and other stored information.

I do not understand however the cause of this behaviour.

Note that I do not use Drupal but I see session related problem everywhere popping up.
And no one mentions the character set.

Jeroen Haan
E-Business & Multimedia Solutions

Sam Moore’s picture

You know, I have time zone problems on my machine too (my host says they need a maintenance window to fix this - we'll see what that brings) - as per post here:

When I disabled the session_regenerate call as per suggestion here:
logins started working as expected, but I have no clear idea why that solution worked.

My time zone problem reveals itself in my inability to set any time zone earlier than GMT. (I also can't set my system clock through normal methods - something wrong at the bios level they tell me).
Anyway if the time is wrong on my syste, but right in my browser, perhaps that would lead Drupal to prefer the wrong cookie based on its timestamp...?

theGlooGuy’s picture

I forgot to mention that we're using 4.6.5 not 4.7

axg70’s picture

I have read thru pretty much every post I could find with word Login in it but still cant find the solution to the problem of logins.

Problem is not just related to first i.e. admin account but with user accounts too.

When you log out it doesnt actually get rids of cookies as when you clock on links for stories it again shows you administrator menus even after you have logged out..
You come back to the site even afer a dat and it logs you back in automatically as admin even though you had logged out.

For users too.. when they log in drupal shows you the same page with user id and password block as if they didn't log in.. You can tell by multiple sessiosn opened for the same user within few seconds.. as users keep on trying to log in.

When user registers.. sometimes site will give you a message that email has been sent and sometimes it doesnt.

When user clicks on one time login link, sometimes it work as intended and most often it doesnt show em the usual message about and showing em the login button..

While working all of a sudden you get access denied messages... same thing happnes for users.. they login and they see access denied messages..

So problem is not limited to first account but for all user accounts too...

Hopefully it will help the developers to address the issue...

Thx’s picture

I had the same problem.
A beta version of 4.7 I installed on february works fine. A trial 4.7.0 installation on the same server doesn't work. No error, but I can't login as a first user. I always end up back at the "create new account" page!

I tried all the solutions proposed here, but I still have the problem.

My environment is:

Apache 2
Drupal 4.7.0
php 5.0

and I'm using windows XP SP2 with IE or Firefox.

Heine’s picture

Do you see messages that you need to provide a valid username & e-mail address? in that case you might need to use the patch .
Getting Fatal error: Call to undefined function: form_*() on Drupal 4.7 ?
When your problem is solved, please post a follow-up to the thread you started.

syoumans’s picture

Thanks! The patch you suggested worked like a charm! I'm going to post my process below in the hopes that it will help others.’s picture

Thanks Heine,
I applied the patch you suggested and now Drupal 4.7.0 works properly!
Thank you!

markhope’s picture

The patch works for me using 4.7.3

I wasn't getting any messages just a page refresh and then nothing.


OOPS - it stopped working after a while - no idea why! ended up upgrading php to include later PCRE library

mattbarton.exe’s picture

I was having a similar problem to this and think I may have found a solution. We're running drupal 4.7 from a subdirectory (neo), and apparently the htaccess was the issue. New logins would go to, but then, of course, the cookie wouldn't transfer over to (sans WWW). So, I modified the htaccess to force the (without the WWW), and the problem seems, for the moment, to have gone away.

Vacilando’s picture

Hi there,

Isn't it incredible that this problem, first reported here on March 24, 2004, still persists?

I have hundreds of users, and all of them, in different browsers (IE, FF), have the same problem:

If they log in via the "user account" page ( in my case ), the page refreshes, but there is no confirmation that the login was successful. So they try over and over again.
But note that they are logged in - it is just Drupal that does not let them know that!!!

If they log in via the main page ( in my case thus ), the login box disappears and everything's ok.

Cache is OFF. Drupal version: 4.6.5.

Anybody out there who knows a fix?

This is a bad bug, already this long long page of people lost in darkness for over two years is a sad testimony.



Tomas J. Fulopp

sijuwi’s picture

We have a local server where I have 3 folders in the root. Our IT fellow has made it that I can reach each one of those folders by using a certain URL. I have an install of drupal in each of these folder giving the corresponding URL as base. When drupal is installed in these folders I cannot login with IE but can with firefox. However if I take one install of drupal and move it directly to the root, ie no subdirectory, then I can now login using IE.

Is this a clue that will help?

sijuwi’s picture

If I bypass the direct URL that I have been given for a subdirectory and I use the root url+subdirectory name, then I am able to login in IE.

sijuwi’s picture

I have checked my three virtual host domain configurations on Apache and they are all identical. Yet I can login using IE on only one even when using the same installation in the root folder for all of the domain names.

This makes me think the answer lies in the OS. Something is defaulting to one of the domains in OS dns settings when drupal fails in IE.

almarma’s picture

"Isn't it incredible that this problem, first reported here on March 24, 2004, still persists?"

But the worst thing is that in the new Drupal 5, the problem is still there. At least I have it!!
I'm trying to migrate from Wordpress to Drupal, but seeing a bug that is without a solution since 2 years ago, is not good for Drupal's image. Any final workaround or still everybody is making personal patches for themselves?

Bill Bumpus’s picture

I've been running into the same problem - upgraded the site to 5.1 in hopes that it might go away, but no luck. Tried deleting cookies and adding a line to the index.php file, but no luck. Anybody found a 5.1 fix for this?

Bill Bumpus

Bill Bumpus’s picture

Hopefully for good! I modified the user module as suggested elsewhere on this thread. That didn't seem to work, so I requested a new password and got into the administrator account. I then set up a new account called "editor" with admin privileges - logged out, logged in as editor, logged out again, logged into the admin account with the new password and it worked!

Not sure why (or if) creating the new account and switching back and forth made the problem go away - but all's well that ends well.

Bill B.

graper’s picture

I recently incountered the same problem on my company website, so I started searching here for an answer. I was unable to log in with IE or FF. The cookie was being set properly, the session table showed that a session ID was being logged, but the uid was not being set.

I forced the uid to be my uid with a sql statement. The site started acting like I was logged in. I looked at the watchdog log and saw that there were no entries in the log about a session being started as if it didn't think I had logged in at all. Since the website is on a hosting company's server and I have other websites on the same hosting server running the same version of drupal, 4.6.5. I check the other sites and I can log in fine with them, so I think it can't be environmental (i.e. a change on the server) it had to be a setting in this one particular instance of drupal.

since I forced my log in, I was able to access settings. I started looking through the settings and saw tha clean urls was turned off. I set it to enabled and saved the settings, it was the only thing I changed. I logged out and was able to log in without problem.

The server is running linux, with apache (don't know what version), mod_rewrite is on. Here is the wierd part with my problem. Clean url's were working. I could get all the pages with a clean url, just could not log in with the clean url's while drupal did not have clean url's turned on. That's because on linux the .htaccess file is set to display clean url's regardless of drupal's settings.

Axel had said it earlier "Enabling of 'clean urls' solve problem."

if you want to be able to log on, try to remove the .htaccess file. for those that have this same problem on a clean install Clean Url's is off by default, you have to remove the .htaccess file until you have succesfully logged in. Maybe look for another file (httpd.conf, or another .htaccess file somewhere), and you must replace the .htaccess before you enable clean url's in drupal, cuase I got an error that stated that the host was not setup correctly for clean url's

what's wierd is that if the clean url's was off this whole time, why did it just recently break? I just found out that one of my co-workers had changed the .htaccess file and put in a new rule. so It looks like my problem was because of a setting and too many cooks in the kitchen :)

Kirkham Systems

goose2000’s picture

I am in the same boat, with 4.7 and thought I'd pass along this tid bit if it helps us figure out what is going on. I used the reset password feature. It creates an email with an encoded link back to the site. It is says this is only good for a one login trip.

I click on this and I'm in the site, no problem, admin rights and all. At this return point, Drupal wants you to reset your password. You can if you want, but it won't work after you leave this current session. As long as you are in the site with this one time only trip, you can do anything, make settings etc.

Hmm, so I'm thinking, why does that work but a regular admin login will not. And this establishes to me, that the site is fully working - minus some usable authentication, lol!

This is frustrating though, anyone with a Drupal hat on hearing this thread?

John A

vidyak’s picture

After a year of using drupal for various things, I now come up with this and it is scary that it is not raising the attention of those who know the design.
So many people seem to be getting the same problem! I have about four contracts pending now..
I have checked all the suggestions. I am keeping my fingres crossed that current sites do not collapse.

demodave’s picture

Resetting password is the only way I can get in from my work computer. But from home, I have no problem logging in. The only difference between my two computers:

Home: IE7 Beta 2
Work: IE6

I don't know if this offers any more clues...but hopefully this can help.

I am really liking the nice clean interface and how easily my site has come together using Drupal. But if my users cannot log in to create content, this is obviously a deal breaker. I am hoping for a solution soon!!

sepeck’s picture

See this is confusing to me. If you look up earlier, you will find mention that it was solved with a server setting.

If it's only IE that is blocking and Firefox, then I would tend to think it is an IE Security settings issue with cookies or some sort of cookie or pop up blocker. I've never had this issue myself with IE, Firefox, Mozilla, Opera....

Add to the fact that a two year old thread issue may have absolutly nothing to do with a Drupal setup 3 versions later.

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

demodave’s picture

I added the INI line in my settings.php file and still no change. I still cannot log in to my site.

sepeck’s picture

And have you tried with Firefox?

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

Phobos Gekko’s picture

That setting did not work for me either, under IE nor Firefox =(

Gekko's Lair of Fire

dustyketchum’s picture

i didn't have these symptoms, but while troubleshooting problems of my own I determined user.module assumes that $user is correct and doesn't do as much error checking as it could IMHO... i'm no php or drupal expert, but I managed to workaround my problem by changing user.module to check for a bad value

function user_access($string, $account = NULL) {
global $user;
static $perm = array();

if (is_null($account)) {
$account = $user;

> if ($user == 0) {
> return FALSE;
> }

// User #1 has all privileges:
if ($account->uid == 1) {
return TRUE;

goose2000’s picture

I tried several of the ideas here. None worked for me and 4.7. So I tried to think when did Drupal work for me on IIS Windows 2000? I had an old download of Drupal and thought I'd try to install that.

It worked (4.6.3)! So, I want to say what this problem is NOT for my experience:

1. Has nothing to do with browsers or cookies.
2. Nothing to do with MySQL, or Drupal database setup, or creation of 1st user - went perfect.

I do think that the site login & sessions (4.7) works much different on IIS that Apache? My next test will be to keep my current MySQL server & PHP and try an Apache version of Drupal 4.7. and see if that behaves any better.

If it does, would point to the use/dependency on the .htaccess file, which IIS does not use. At least I have a difference in results and process of elimination I can follow.

For the record:

Windows 2000 / IIS
MySQL 4.0.21
PHP 4.4.2 CGI

Last known good Drupal Site - 4.6.3 (fresh install & DB)

Good luck Drupinites!

John A

roterl’s picture

I think it related to cookies per domain
I have multi-site system one running as and the other as

Using IE, if I login to one of them, I'm fail to login into the other, until I'm deleting all the cookies.
The solution noted above, about removing the IE Automatic cookies handle also work.
Using FF everything work ok


rbarrphd’s picture

My drupal-based Civicspace site behaved as you described: logins failed for IE6 but not Netscape. After reading this loooong thread and trying some of the .htaccess changes that my hosting service would allow, here is what fixed it for me, based on hints others have provided.

Just as mentioned in the original post, the drupal site home was a subdirectory off of the main domain name directory. By creating a subdomain pointing to that subdirectory, and using the subdomain name to enter the drupal site, the problem disappeared.

Specifically, for if's home directory is /home and the drupal site is in /home/reunion/ with the URL, create a subdomain pointing to /home/reunion/ and browse to the subdomain. IE seems to work fine that way, for some reason.

I hope that this helps some others with this frustrating and elusive problem.

cmsproducer’s picture

After a good research session and looking for a solution on, I was able to find a solution that works for me in consistently in Drupal 4.66 and 4.7. The problem is obviously caused by an anonymous cookie string being used in the logged in session. To solve the problem, in the user.module file in the modules directory, edit the lines 947 - 954 in the user.module of Drupal version 4.7 contains the function that authenticates users and creates a $user state variable.

function user_authenticate($name, $pass) { global $user;

// Try to log in the user locally. Don't set $user unless successful.
if ($account = user_load(array('name' => $name, 'pass' => $pass, 'status' => 1))) {
session_regenerate_id(); //iDonny - create a new session
$user = $account;

By regenerating the session ID, you will drop the anonymous ID and pick a new one for the logged in session - You can see the detailed solution to this common bug by checking this Drupal resource.
iDonny - WCMS Design, Devt., Marketing & CRM

rbarrphd’s picture

I am working with drupal 4.6.6-based Civicspace 0.8.3, and am a struoggling rookie. Can I use your five-line function user_authenticate($name, $pass) in place of 4.6.6's 43-line function, lines 852-895 in user.module?

Thank you for any help!

cmsproducer’s picture

If you have the same problem, then you can add the line that's commented with my name //idonny just after the user is authenticated in that fucntion to clear the old session ID. Let me know in the morning and I can assist you some more if you do not figure it out yourself
iDonny - Web Content Management System Design, Development. & CRM

Sam Moore’s picture

Just applied iDonny's suggested edits to user.module to a brand new 4.7.1 install, and voila, problem solved.
See above at


Joe Murray’s picture

This is line 1006 in 4.7.3, but didn't work for me.

Joe Murray


syoumans’s picture

Okay, I've been wrestling with this problem for a while and I just solved it with some help from the above postings. Here's my story:

Last week I noticed that I wasn't able to login to drupal anymore. I would enter my user/pass and the screen would simply refresh and not take me anywhere. I've installed drupal several times and never had this problem. After lots of futzing around I decided to install a fresh drupal 4.7 and create new database tables.

Now things get really interesting: drupal wouldn't let me create a new account! Even though I entered in a username (admin) and email address, drupal didn't think I had entered anything. My values were even displayed in red in the text fields just to taunt me. I went into the user.module:user_validate_name function and added an echo statement to print the $name variable. The $name value was empty inside the function.

I then took a long walk. When i came back I started browsing through the forums and bug postings and found this thread. I tried many options, but none of them worked until I found this patch: (look in the attachment to comment #7). I installed it in my includes/bootstap.ini file and it worked like a champ!

In trying to recreate what and why this happened, I realized that I recently turned on register_globals in my global php.ini file. So Drupal was working fine before, then I reset the ini file and didn't work on drupal for a week, so when I came back, it looked like a big mystery. An odd not, however: I tried to set register_globals to off in my settings.php file and that didn't solve the problem. I'm guessing that it was a syntax error on my part.

My setup is this: MacOS 10.4 / Apache 2.2 / PHP 5.1 / MySQL 5.0.

Heine’s picture

Security code was added to prevent attacks via an uninitialized $base_url, This security code only executes when register globals is on, because it's only relevant in that situation. It simply removes not allowed variables from the $GLOBALS array.

Unfortunatety $GLOBALS contains a reference to $GLOBALS itself in PHP 5 (and who knows in which other php versions) and $GLOBALS wasn't in the allowed list: result all vars obliterated.

There have been multiple threads on this problem, but most people simply get a 'you need to enter a username and a password', not an empty form.

Glad you found out.
When your problem is solved, please post a follow-up to the thread you started.

mountain girl’s picture

hi syoumans,
just for the record
took note of your fixit via comment #7 in the other post -- it fixed the ie login problem, but the ff login problem persists
so that's a good start...

saltspringer’s picture

I was having the same problem, followed syoumans advice and it solved the problem - thanks for the help.

Okay, I've been wrestling with this problem for a while and I just solved it with some help from the above postings. Here's my story:

Last week I noticed that I wasn't able to login to drupal anymore. I would enter my user/pass and the screen would simply refresh and not take me anywhere. I've installed drupal several times and never had this problem. After lots of futzing around I decided to install a fresh drupal 4.7 and create new database tables.

Now things get really interesting: drupal wouldn't let me create a new account! Even though I entered in a username (admin) and email address, drupal didn't think I had entered anything. My values were even displayed in red in the text fields just to taunt me. I went into the user.module:user_validate_name function and added an echo statement to print the $name variable. The $name value was empty inside the function.

I then took a long walk. When i came back I started browsing through the forums and bug postings and found this thread. I tried many options, but none of them worked until I found this patch: (look in the attachment to comment #7). I installed it in my includes/bootstap.ini file and it worked like a champ!

In trying to recreate what and why this happened, I realized that I recently turned on register_globals in my global php.ini file. So Drupal was working fine before, then I reset the ini file and didn't work on drupal for a week, so when I came back, it looked like a big mystery. An odd not, however: I tried to set register_globals to off in my settings.php file and that didn't solve the problem. I'm guessing that it was a syntax error on my part.

My setup is this: MacOS 10.4 / Apache 2.2 / PHP 5.1 / MySQL 5.0.

vidyak’s picture

I am using drupal 4.6.7 .. this is crazy of course, since my other sites work beautifully

neuromusic’s picture

I had originally installed Civicspace, but have since upgraded to CiviCRM 1.4 and Drupal 4.7. Then I changed servers from php4 to php5 when I ran into this problem. Replacing civicrm with the one built for php5 let me log in.

abqaria’s picture

It was working great...on firefox , i logged out and never been able to log in again

when i switched to internet explorer ...i mangaed to log in

whats happening ?

witigonen’s picture

I too am having this problem. Deleting all of Firefox's private data will solve the problem but only temporarily. None of the above solutions have worked for me.

GiorgosK’s picture

if it works (you probably get some warning "headers already sent")

then you might want to disable caching (admin/settings cache settings)
and you won't have this happening again

chios sightseeings

srcnyc’s picture

I'm having this problem as well. I've tried all of the fixes offered above, but nothing has worked for me. The only way I can log in either as an admin or as a user is by requesting a new password. I've tried deleting cookies, my cache and my history; this is for both IE and FF.

Since applying some of the fixes above, the only change is that it no longer lists me as logged in, even though it recognize me; it just says there's one guest online.

I wasn't using clean URLs because my server isn't configured for that, and I'm not sure my host will allow that.

I really need to get this fixed; I need to launch this site ASAP.

Any ideas much appreciated.

GiorgosK’s picture

disable and erase from module directory as it creates the double login problem

it worked for me

chios sightseeings

mountain girl’s picture

thanks kongeo -- i have applied another couple of fixes that got ie logins working. your suggestion to disable cache has made things function for me in ff too. though i'd have to admit, if it improves site speed, i'd prefer to have cache enabled -- but given how annoying this login problem is, a worthwhile trade-off....

and now i can get on with other things! :)

cmsproducer’s picture

A patch has been posted:
Beginning entry #46 of and after if there are any subsequent updates to the patch.
iDonny - WCMS Design, Devt., Marketing & CRM

GiorgosK’s picture

with a clean browser cache and cache disabled you get the same old problem of reporting header already sent etc.

Applying the original patch from does actually work for me so far.

chios sightseeings

cmsproducer’s picture

Please specify the entry # when you refer to the original patch. The patch that I submitted first did not write the session ID into the DB; the second ones does (and that might be related to the cache issue - I have to find out how). I am slowly looking for a remedy tot hecache issue (I have a project in my hands and will only be able to dedicate more time after...)

iDonny - Web Content Management System Design, Development. & CRM

srcnyc’s picture

I think I'm going to hack in by requesting a new password (which is the only way I can login), and then enabling htaccess, which I hadn't been using before, since that seems to have worked for some folks and it's the only thing I haven't tried yet! Thanks though.

For reference:

I'm using 4.70
This is happening in both FF and IE.
After applying various patches suggested above, now the site never registers that anyone is online (guests or users). Originally, it would register that I was online, but not give me access to my account. The site had been working fine for the first couple weeks, and then this started. I don't know what I might have changed to bring this on.

You can see the site here:

cmsproducer’s picture

You do not have to request a new password, just delete your cookies and you should be able to get in.
The whole issue is caused by a persistent cookie/ session ID. I will investigate your situation more (and that of others that seem to continue to have the issue) and post any findings.

FYI: On my installation, to makes ure that I am handling my cookies separately, I changed the name of the session ID in settings.php. Chnaged it from SESSID to something else (by default all PHP applications use the earlier). Cookies should not be mixed from many sites since your browser should only hand back cookies to the same server that places them.... I will post findings once I have something.

iDonny - Web Productions: Web Strategy, CMS Design, Branding, & Production

Rosamunda’s picture

None of this worked for me.

I can still enter the site using Firefox, but cannot do it using IE.
Maybe the solutions that iDonny suggested I´ve done something wrong...
I´ve read soo many posts already that I don´t know where am I now...

Please, can you post you solution?
Could it be this: (on user.module)

user_module_invoke('login', $form_values, $user);
//Silencing the next 3 lines and moving their actions lower after authentication
// $old_session_id = session_id();
//  session_regenerate_id();
// db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

function user_authenticate($name, $pass) {
  global $user;
  // Try to log in the user locally. Don't set $user unless successful.
  if ($account = user_load(array('name' => $name, 'pass' => $pass, 'status' => 1))) {
  // next 3 lines: once authenticated, assign variable, regenerate the session ID, and update it in the DB
  $old_session_id = session_id();
  db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);
    $user = $account;

It didn´t worked for me ... It feeps happening the same problem...

I didn´t try this patch yet:

=== modified file 'a/includes/'
--- a/includes/	
+++ b/includes/	
@@ -136,7 +136,7 @@ function conf_path() {
 function drupal_unset_globals() {
   if (ini_get('register_globals')) {
-    $allowed = array('_ENV' => 1, '_GET' => 1, '_POST' => 1, '_COOKIE' => 1, '_FILES' => 1, '_SERVER' => 1, '_REQUEST' => 1, 'access_check' => 1);
+    $allowed = array('_ENV' => 1, '_GET' => 1, '_POST' => 1, '_COOKIE' => 1, '_FILES' => 1, '_SERVER' => 1, '_REQUEST' => 1, 'access_check' => 1, 'GLOBALS' => 1);
     foreach ($GLOBALS as $key => $value) {
       if (!isset($allowed[$key])) {

As this mess the globals stuff, and I´m not a programmer and once have made a mess with the register globals... Should I try that on the file??

Hope someone can help me :-)


j0k3z’s picture

Nothing is working for me.

So does this mean I have to completly reinstall everything?

beginner’s picture

If you can say how to reproduce, post there:

From the forum thread, it seems many people have this problem, but the majority don't.
Is this issue also related to the other issues about cookies and double login?
In any case, until those who experience the problem can tell clearly under which conditions this problem occurs, and until they tell exactly how to reproduce the behavior, there is little that can be done to fix the problem.
this issue IS critical for those who experience it, but until we have more precise information (step by step intructions to reproduce), pretty much little can be done about it.
Once you've made sure the problem is not cause by a contrib module, and you have agreed between yourselves on how to reproduce, you can then set this issue as critical.

Healing with Sexual Relationships.
We live in a world of solutions.

Acert93’s picture

I have had 2 different domains do this (specifically where IE no longer allows you to log in; both times FF was fine). The site was fine, I returned to the site the next day and it asked me to log on. At this point it started the "loop". I am sure those of us who are having this issue would be more than happy to take you step-by-step how to replicate the issue if we could. I know you are trying to be helpful but it is difficult to produce the information you request. I have 2 sites afflicted and another 3 that are not. It is frustrating being incapable of expressing what causes the problem as it surely is for yourself not being able to assist with a problem you cannot replicate.

andylippitt’s picture

I was trying to track down what I thought was a similar issue (turned out they just didn't have cookies enabled) but stumbled across the fact that when you log in, TWO headers are sent in the response headers for the php session cookie with two different values. When things are all working nicely, the client picks up the second one and returns it on the next hit. I wonder if some browsers under some conditions are picking up the other one whatever it is?

goose2000’s picture

Have a look at this:

There is more good information on the login trouble here.
I hope a formal fix will be applied to the next drupal interation

John A

abqaria’s picture

i disabled cachin and i donot get the problem anymore
i am using 4.7.2

Martin Frank’s picture

I have the same problem... suddenly my site doesn't recognize any users / passwords anymore. I don't know what to do.

After reading through this far too long thread, it seems that after two years the Drupal developers still don't know what causes the problem and how to fix it. Is this problem really given the attention it deserves?

This problem is a killer problem. I suggest that it be given the highest developer priority. What's the use of setting up a website with Drupal, if your users cannot access it? All other good Drupal features immediately become irrelevant.

Users register once, and if they cannot login next time, they will forget your website.

(Meanwhile I checked the pending bugs.)

I am shocked to see that this problem is not among the critical pending bugs.

How do others deal with this problem? How do you know for sure users will be able to access your website reliably? I can erase my cookies and change settings on my computer, but what about the users OUT THERE?

homepage and website of the gay swiss
writer martin frank

abqaria’s picture

when i faced the problem , i solved it by disabling the cashing

then i faced the same problem again

i solved it by clearing history and cookies

any new ideas ?

GiorgosK’s picture

try logging in twice, and then try disabling modules and see which one might be causing the problem.

for me caching disabled did the trick,
later on I had to disable the developer module.

Chios Greece sightseeings

flipmode’s picture

Fix for logging in as a user or admin and returning to the login screen or a login not taking

I read in another post to make a change in the user.module (located in the "modules" folder of your install) for a fix. Open user.module and search for the following:

$old_session_id = session_id();
db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

I commented out //session_regenerate_id(); and then it worked perfectly.

Change to...

$old_session_id = session_id();
db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

This was a strange issue for me because most of the suggestions here seemed to resolve the issue at first then it would return. I believe this edit resolved my issue.


lisar’s picture

I was also having the problem of it not working in i.e. but working in firefox. I commented out the above as you said and now it works fine.


skcombs’s picture

This did not help me. I have tried every suggestion I've found at Drupal and cannot log in. I've checked my base url, removed cookies, cleared the session table, made suggested code changes to user.module, checked the .htaccess.

When I first started using drupal shortly before 4.70 became a final version, it all worked fine. Our site needs to go live soon, and it requires that logins work. I am getting desperate to have an answer to this.

  • I am using Drupal 4.7.0, Apache version 1.3.36(Unix)
  • PHP version 4.4.1
  • MySQL version 4.0.27-standard

Logins fail completely, on IE, FireFox, Netscape and from every computer I've tried. Does anyone understand this problem sufficiently to offer a bona fide solution?

mfitch’s picture

I had applied this patch before - upgraded to 4.7.3 and the problem came back.
This fix solved the IE login issue for me also.

(I also tried w/o success:

function user_authenticate($name, $pass) { global $user;

// Try to log in the user locally. Don't set $user unless successful.
if ($account = user_load(array('name' => $name, 'pass' => $pass, 'status' => 1))) {
session_regenerate_id(); //iDonny - create a new session
$user = $account;



two2the8’s picture

While this was a pretty simple solution, it's really not cool to have to edit a core module to make the site work for our users... still, though, I'm glad it works. Thanks everyone for all your help!

uknewperson’s picture

Didn't realise I actually had this problem for a few weeks as just thought it was a quirk of my browser. Anyhow, tried disableing cache but that didn't work, then tried the idea on node 61900 and that didn't work. Then tried inserting the command into the settings file suggested by Grymwolf below ( sorry can't see exact name as I write this) and that didn't work. Then tried commenting out this line within the user module and IT SEEMS TO WORK BEAUTIFULLY! For info , I'm using 4.7.2 on 1and1 shared server. Nice work people. T

Stephen Winters’s picture

I was using Drupal 4.7x and wasn't able to log into the church website I'm developing (After I logged in, the login and password box would reappear empty, as though I hadn't logged in [and yet the "Online Users" would show one user, with me listed, but otherwise I wasn't shown as logged in]). Upgraded to 4.73, still unable to log in. (I had two browser windows open, one at the website and the other for the website control panel) As soon as I commented out that line "//session_regenerate_id();", I am now able to log into the website.

(note: I don't know if I had to do this or not, but after I commented out that line, I navigated away from the website with the other browser window, deleted the cookies to the website from my computer, Deleted all the temporary Internet files [Tools>Internet Options>Temporary Internet Files>Delete Files], navigated back to the website and logged in without any problem.)

Thanks for that solution to a troubling problem!!!

Best Wishes,
Winters Sewing
Winters Sewing: Upholstery Information Website

wilco’s picture

The COMMENTING OUT LINE #970 of user.module in Drupal 4.7.3 fixed my headache.

I've been working with the following setup:

  • Red Hat Entreprise 3.0
  • MySQL 4.1.14-standard
  • PHP Version 4.3.2
  • Apache 2.0.46
  • VirtualHosts up the wazoo!

Almost every site is configured in weird directories all over the server, why? I don't know (maybe to make life interesting.) I grappled with this issue for a few hours and came across this solution JIT! I was going to give up and start a fresh install of Drupal. You know, the "scratch" technique. Frankly, I didn't think that would help my frustration at all. Even thought of giving the CVS a shot. But heaven's light shun down and bore the fruits of my great happiness.

Thank you Brady!

william roboly - nurf productions -

william roboly - robocrow digital inc. -

seken’s picture

This solution worked for me! (I’m running Drupal 4.7.3) I have broken my head and wasted several days trying to figure out this problem. I had tried many solutions mentioned in this page, including the cookies solution, but none of them worked.

Acert93’s picture

Commenting out session_regenerate_id() in the user.module has worked for us and has worked for over 60 days without a single relapse for us or any reports of such from our users. A lot of our users (we have about 200) were complaining about this and the log file was showing MANY users requesting their password EVERY time they tried to get to the site (i.e. they thought they were not using the right password when infact the site was broken).

I have been waiting to respond just to make sure there were no issues and/or the problem came back. 2 months seems sufficient. What reminded me to post my experience with this "fix", oddly enough, was I was doing some updating and overwrote my user.module with the standard 4.7.4 version. Not more than 10 minutes after updating the user.module with session_regenerate_id() left active we began seeing this login bug appear. Very frustrating! So I commented out session_regenerate_id() and things seem to be back to normal :)

This was the first "fix" I tried in this thread and have not tried any others. It seemed the easiest -- and easiest to undo -- and seemed to worked for a number of other users. I was a little hesitant to change a core module, but after months of no solution, frustrated users who stopped trying to login, and so forth I decided to give this a try. I am glad I did. It may not work for everyone, but it worked for us.

Drupal 4.7.4 (has occured on all 4.7.x variants I have tried as well as 4.6)
Linux (Kernel 2.4.21-9.0.3.ELsmp)
Apache 1.3.33 (Unix)
PHP 4.3.10
MySQL 4.0.27-standard

FableForge’s picture

Man, its been a long day, I tried everything. Finally this did it. Unfortunately, it seems this route opens a potential security hole, but man, at this point I dont know which is worst. For any drupal developer reading this: guys, its been 3 years, I'd help if I was a programmer, but.. yeah, a main universal fix needs to be made and posted on the main page somewhere. Greetings all.

jvdwaa’s picture

Well, I tried to figure out the problem too.
I couldn't login using FF on one machine, no problem on another one. IE worked fine too.
Read a lot about the cookies, but didn't understand which cookie.

Then it suddenly hit me: My site was probably in a blocked site-list in FF.

And indeed, it was. Under Tools/Options Privacy Cookies Exceptions, remove your own site name (you might have to restart FF).

Problem solved. :-)


9802008’s picture

Logins for both browsers worked fine until I changed this line:

ini_set('session.cookie_lifetime', 200000);
in sites/default/settings.php


ini_set('session.cookie_lifetime', 0);

IE login then stopped working. Changed the value back to 200000 and it works.

reggie75’s picture

What you have done WILL work.
Only thing is you need to DELETE COOKIES after you do this.

Tools > Internet Options > Delete Cookies.

I struggled on the login bug for a long time. This solved it for me. Hope it helps.

Fons’s picture

I think I've found a clue to what may be at the base of the problem that seems to be a pain to many users. I've got a site to which I forward a domain,, and I can't login with it form IE, although I can from firefox. I can login form IE if I don't use the forwarding from, but access the server imediately.

I noticed that firefox displays the url to which the is forwarded, and IE does not. It keeps displaying

I'm using PHP4.x, Apache2, on Suse9.3 with drupal 4.7

On this site, they hint at the solution for users, but I don't want to burden my users with this. I tried and it works, so it has to do something with the IE forwarding policy.

Another one:

Can anyone turn this into a global drupal solution?


dcasey’s picture

When logging in through the block, it redirects me to the root If I started there, I am logged in. However, if I started at, I get redirected to and it appears that I am not logged in. If I go back to, there I am logged in. It appears that Drupal thinks these are two different sites, which could be a feature (playing with themes for a non-logged in user). I would just like to be redirected to www or / depending on where I logged in from. Oh...yes, my site's $base_url (sites/default/settings.php) is set for / not www.

An obvious choice is to uncomment the auto redirect in the .htaccess, so your user will never see the non-$base_url. However, it seems that the login would query the URL to see where to redirect (although, I have not looked into the code).

anneeasterling’s picture

You know it almost seems to easy, but I think this could be the answer for many of us. Drupal even puts a htaccess file with the clues if we are smart enough to figure it out.

Our base_url was without the www, and the error occurred visitors started at Editing the htaccess file for a permanent direct solved the problem -- Hooray!

Happy day,

sraisz’s picture

I am a new user and so I'm not familiar with Drupal. I'm trying to install version 4.7.3 and getting the same of login not taking.

However I also get this error when adding a user:

warning: Compilation failed: characters with values > 255 are not yet supported in classes at offset 27 in /home/ekaji/ on line 244.

If I delete cookies as suggested in many of these posts then I can log in.

Joe Murray’s picture

I find I can login once by requesting a new password. Not that it solves the issue, just makes debugging slightly easier.

Joe Murray


Acert93’s picture

Yeah, I see the same users on my site request a new password on a regular basis. I have asked them and they say they remember it but it won't work. New password works once.

Gwendelen’s picture

I have several users who are regularly using the password request workaround for the login "not taking" issue. I am fairly confident at least with my install, that this issue is limited to ie users.

JamesVL’s picture

This is also a bug in PHP's behavior with global variables. This "login issue" can manifest itself from other bugs that involve session ID's and cookies.

This fix is different.

Quick Fix

Change Drupal's index.php so that last couple of lines become

$GLOBALS['tempUser'] = $user;

Problem Background

Without the above fix, PHP is not importing stdClass global variables into the sess_write() function. This is incorrect PHP behavior; your server's OS and PHP build influence whether or not this shows up for you.

When Drupal gets to the sess_write() function (one of the last actions it takes for a page), it updates Session information based on the current $user object in global scope - namely, it uses $user->id in its updates of the session table.

Since $user isn't define in the function's scope, it uses a default of 0 which causes the correct session information to be present but with a userID of 0 (anonymous), which sends the user back to the login form.

I don't know PHP engine internals, but putting a duplicate of the $user variable directly into the $GLOBALS array fixes it (for me).

I've written more detail and submitted a test case which demonstrates the buggy behavior at the bug report filed at

JulianWB’s picture

There seems to be a lot of confusion over log in problems - mostly because there is more than one problem showing similar effects.
This entry (update index.php to reference $user) fixed my problem - which was:


  • New install: create the first account
  • Set the password - on OK I would get "you do not have permission..." etc, and the login would reappear
  • Subsequent attempts to log in would fail
  • Set password for uid =1 with UPDATE users SET pass=MD5('newpassword')

    Then could log in, but at each new GET I would see "you do not..." - and the login prompt would reappear.
    Entering the username and password would then show the expected screen - in this way I could use the system but had to reenter credentials every time I fetched a new page.

    Administer-> Message showed a session created for 'firstuser' each time - then access denied for Anonymous
    The uid corresponding to my session in t sessions table never got updated - remained 0

    Paul Armstrong’s picture

    much appreciated.

    with a fresh install the uid in sessions was always being overriden. i could log in, but then as soon as i navigated anywhere i was "logged out" (unless i kept manually setting uid to 1).

    for background i'm running: PHP 5.2.0 (cli) (built: Nov 8 2006 15:08:22)


    johnchalekson’s picture

    adding $GLOBALS['tempUser'] = $user;


    Chris Lozinski’s picture

    Thanks John for this simple fix.

    One man's struggle is another man's fortune!



    Peli’s picture

    siaiweb’s picture

    I LOVE YOU man, I spent hours and hours on the different solutions suggested and yours was the good one!

    tohann’s picture

    When I visited my site I typed in and tried to log in. But when the login failed I ended up on I modified my settings.php file to have the full in the $base_url variable and now the problem is bye-bye.

    I hope this helps someone out there.

    Rollie’s picture

    I've got this problem too. I have to request a new password (to get the one time log in link) everytime I want to log in to my drupal site. I've read through about 50% of this thread and now I'm totally paralyzed.

    PS. Erm, seriously - this thread is, what, over two years old now? Could it be that the session/login code might need some rewriting?

    Rollie’s picture

    I've had this problem for about a week but something I did by following one of the above posts seems to have fixed it. I'm not sure which one though - sorry.’s picture

    in tohann's post "I was having this exact same problem", he states the following:

    ""I modified my settings.php file to have the full in the $base_url variable and now the problem is bye-bye.""

    i modified my settings.php to include http://, as well as modified my .htaccess file to force www in my site address...

    this has gotten me as far as being able to log in immediately after clearing my cookies, in both IE and Mozilla... but if I log in, do some things and then log out... i have to clear my cookies in order to log back in.

    once logged in, i can view the logs and see that i've been "logged" in each of the times where my browser failed to go anywhere.

    something else to note... i was originally installing this into a subdomain... ie... and i couldn't even get this far. so it is a step in the right direction, however i still can launch my site if my users are expected to constantly clear their cookies just to log in.

    just my 2 cents.

    Ole Martin’s picture

    I had problem with log in - I had to log in two times before it takes. After I disabled " Clean url" it's seams to work ok.

    Ole Martin (joomla) (My first step with Drupal)

    a1437053’s picture


    1. Installed drupal. Worked well for 2 weeks.
    2. Suddenly, I can't post blogs. I complete the blog form, but when I click submit, the page reloads and nothing is posted.
    3. Tried to log out and sign in, and NOW I CAN'T LOG IN!
    4. Hosted on bluehost, along with a moodle and elgg site. NEITHER SITE SIGN-ON WORKS, so I'm thinking it's a server issue. Any help?

    1. Cache clearing. Browser and drupal database.
    2. // session_regenerate_id();
    3. all kinds of things on this forum.

    I called bluehost . . . they were useless help . . .

    Glad to see I'm not the only one, but WHAT CAN I DO?

    I'm at


    a1437053’s picture

    a1437053’s picture

    I was playing with browser cache at my laptop at school . . . (earlier I had cleared cache AND tried logging on another computer)

    and suddenly, ALL SITES are working.

    Amazing. I am scared because I know it will happen again and I don't know what I did to fix it!


    a1437053’s picture

    From my hosting service:

    "The admins found an issue with the configuration of php on Monday and had it fixed
    by Tuesday night. There were problems with the post max size limits set in the
    default php configuration file. This should now be working for you, please let
    us know if you see any more issues. Again we apologize for the delay in this reply."


    eccweb’s picture

    Just like to say that commenting out the //session_regenerate_id(); line in user.module version 4.6. worked like a charm for me.

    Thanks to whoever back in the line of posters on this thread suggested it!!!!!!!!


    Sam Moore’s picture

    Commenting out //session_regenerate_id(); in user.module worked for me too - Drupal 4.7.4, fresh install.

    utterly_lost’s picture

    hashing out session_regenerate_id(); did it for me, im using php 4.3.2


    jruberto’s picture

    If you are experiencing this & you are running PHP5.2.0, definitely check out

    Jim Ruberto

    manoj.deshmukh’s picture

    when i type

    then instead of login page ,page not found error occurs
    and also home page also not found please suggest the solution .



    royce’s picture

    Thanks. This was the magic fix for me: MySql, IIS on XP SP1, PHP 5.2 in CGI mode

    herb’s picture

    I've had problems trying to create the first user since I started playing with Drupal 6 months ago. Both machines I'm using are windows based, with one running under IIS, and the other WAMP.
    It has always been a "thrill" - usually after two days of turning off the virus and firewall protection, letting browsers do pop-ups, clearing cookies, using Firefox, IE, and whatever else is suggested in these threads,, somehow the first user "takes"?!?! With 4.6 it seemed to be easy, but now with every 4.7 version it's a challenge.
    I've given up trying to resolve it. I'm a definite amateur, but for a new install, I now just drop the two user tables and then restore them using an export of these tables from a functional drupal site.
    However, this won't help you if you haven't gotten your first site running yet. :-)

    ladycentaur’s picture

    For some reason drupal comes with the config.php file as NON-writeable when you download it. Anytime you can't log in with that first account it is most likely a config.php problem. Before you start looking for any other solution make sure you temporaritly change the permissions on your config.php file to write. If you don't have it set so you can write to it then it won't save your first username and login to Drupal because the config.php file is blocking the creation of your admin ID.

    TheWhippinpost’s picture

    Witnessed this same problem after launching live site yesterday - Could log-in with Firefox, but not IE7.

    Today however, no problems... I use the Maxthon browser (built a-top of the IE7 engine) which saves all the tabs from the previous session. So when I re-opened Maxthon today, I found that I was already logged-in (Also witnessed in IE7 itself, just to allay any Maxthon-only ambiguities).

    It might be worth adding that this logging-in issue never cropped-up on my locally-run test site.

    A simple thanks to those that help, a price worth payng for future wealth.

    markusveralius’s picture

    I was having this problem yesterday, where I could view my php pages ok, but could not log in as any user type. I searched this thread and tried deleting cookies / cache - no joy.

    I then remembered that we were trying to use IIS on port 80 and also apache through port 8888. I had changed my apache conf file to reflect this, but maybe I hadn't changed it elsewhere. The result was that I could see my pages, but could not log in.

    To fix the problem I disabled IIS temporarily and then ran apache through port 80 again. Lo and behold the login now works. Now I need to go back and work out how to use IIS and Apache web servers at the same time, and so that user log in can work.

    Any ideas to get this working are appreciated!

    nukern’s picture

    A combination of 3 things has helped me. This is after trying various methods suggested here

    (1) Using clean URLS (must)

    (2) commenting session_regeneration_id()

    (3) Editing index.php at end by following

    $GLOBALS['tempUser'] = $user;.

    THis was crucial for me and OS + php combination affects the session id + cookie I assume

    2xe’s picture

    Thank you for this post. The thing that did it for me was adding $GLOBALS['tempUser'] = $user; to index.php. I do not use clean URLs and did not comment session_regeneration_id()

    The strange thing is that I have to identical systems running debian with Apache 2.2.3 PHP 5.2.0-8 Mysql 5.0.30 and Drupal 4.7.x

    I copied the files and databases from one computer to the other. When logging in, it seemed the cookie/session wasn't stored correctly because I only could view one page before I was logged out.

    Now the systems are still identical, however the $GLOBALS['tempUser'] is set in the one configuration...... Well, thanks again for this post -- too bad it was this far down in the list (spent 5-6 hours figuring this out!)

    tihidesigns’s picture

    i had not set the

    $base_url = "my site" in the config file.

    no snags after i set it.

    just my two cents.

    -- eat you peas...’s picture

    I cleared my cookies and I cleared my internet history and doing both of these things fixed it for me.

    subspaceeddy’s picture

    I just started having this problem...... eventually figured out that the closing ?> on the bottom of the template.php file had some extra carriage returns on the end which would have been output, causing php to send headers, so that when the headers should have been sent properly, they had already gone.. fix (for me) is to remove closing ?> from theme template files.

    the watchdog errors i had were

    error	php	2006-11-28 17:28        Cannot modify header information - headers already sent ...
    error	php	2006-11-28 17:28	session_regenerate_id() [

    Clicking on session_regenerate_id() resulted in:

    Message	session_regenerate_id() [function.session-regenerate-id]: Cannot send session cookie - headers already sent by (output started at {mywebroot}\themes\{mytheme}\template.php:204) in {mywebroot}\modules\user.module on line 966.
    johnmar’s picture

    My test site for Drupal 5 Beta 1 have the same Login problem.

    Does this means that this problem have reincarnated into Drupal 5? What do you think chaps?

    almarma’s picture

    Please, can you explain a little better the solution? I'm testing Drupal 5 (final) and I have the problem with the sessions.

    Thank you very much

    Chill35’s picture

    Read this first, please :

    That may or may not solve your problem.


    mgerra’s picture

    Recently upgraded to 4.7.4. Found it impossible to login via IE on WinXP, but OK through Firefox on IE and Mac, and Safari. Driving me absolutely nuts. Here's solution that worked for me -- I'm in the process of backing each of these out to see if only subset is needed. Hope this helps someone.

    Commented out following in user.module:

    Added line below drupal_page_footer(); in index.php:
    $GLOBALS['tempUser'] = $user;

    Added this to my settings.php:
    ini_set('session.auto_start', 0);

    Set options in IE > Internet options > Privacy tab > Advanced:
    override automatic cookie handling
    accept first-party cookies
    always allow session cookies

    johnmar’s picture

    Commented out following in user.module:

    Added line below drupal_page_footer(); in index.php:
    $GLOBALS['tempUser'] = $user;

    Added this to my settings.php:
    ini_set('session.auto_start', 0);

    Set options in IE > Internet options > Privacy tab > Advanced:
    override automatic cookie handling
    accept first-party cookies
    always allow session cookies

    I almost have done all of the solutions here, nothing works! :(

    What surprises me though is, does not have this problem. Are the developers hiding something from the community?

    bigtoe416’s picture

    Have you tried adding session_write_close(); to the end of the index.php file?

    johnmar’s picture

    Yes I did add session_write_close(); at the end if the index.php file! Nothing happens! Still the same, no success in lgging in!

    reggie75’s picture

    just clarifying:

    you dont need to *add* this line, you need to modify the existing line in settings.php to this line (ie swap 20000 with 0)

    after this, you need to delete all your cookies in your browser for it to start working, as the old cookie has the old value and wont get overwritten.

    or you can test from a browser that has never hit your site before.

    it seemed to worked for me,


    hobbsy’s picture

    IE 6 on WinXP login problem + solution
    mgerra - December 5, 2006 - 00:06

    Recently upgraded to 4.7.4. Found it impossible to login via IE on WinXP, but OK through Firefox on IE and Mac, and Safari. Driving me absolutely nuts. Here's solution that worked for me -- I'm in the process of backing each of these out to see if only subset is needed. Hope this helps someone.

    Commented out following in user.module:

    Added line below drupal_page_footer(); in index.php:
    $GLOBALS['tempUser'] = $user;

    Added this to my settings.php:
    ini_set('session.auto_start', 0);

    Set options in IE > Internet options > Privacy tab > Advanced:
    override automatic cookie handling
    accept first-party cookies
    always allow session cookies

    This log-in/cookie/session problem has been driving me crazy for the past 4 hours, and has not left me with a happy first impression of Drupal! :(

    Trying to install Drupal 4.7.4 on my home PC (localhost)

    Set up WAMP
    (which includes:
    - Apache 2.0.59
    - PHP 5.2.0
    - MySQL 5.0.27
    - PHPmyadmin

    My browser of choice is Firefox 2.0

    I finally seemed to have fixed things (after following many methods - none of which worked), by simply following the first two things on mgerra's post above:

    Commented out following in user.module:

    Added line below drupal_page_footer(); in index.php:
    $GLOBALS['tempUser'] = $user;

    I also had problems with setting up an initial user on my home WAMP server.
    There didn't seem to be a mail server installed so it couldn't send my initial set-up details for the Drupal admin user

    I think I'm up and running now, but I wish this process could have been simpler... like I said I just wasted 4 hours reading through message board posts to fix a problem at the first hurdle

    Having said that -- thanks for all the hard work you put into this free project (and to all the forum posters who give up their time to try and help out!)

    traeumerle’s picture


    Linux, MySQL 5.0.27, PHP 5.2.0, Drupal 4.7.4 using mysql interface not mysqli (which is not included on my shared host).

    I also did a $GLOBALS['tempUser'] = $user; on update.php and xmlrpc.php so that I'm able to run them too.

    The only problem I have is that I get kicked of when using an upload-form from upload.module. After the first javascript based upload I'm logged of. This also happens when manually opening http://domain/upload/js

    traeumerle’s picture

    reading this issue and using the patch from comment #9 the upload/js-problem is fixed for me too. Even without commenting out session_regenerate_id(); and $GLOBALS['tempUser'] = $user; in index.php.

    stecrv’s picture

    After 4 days, and unlimited number of solution, it's works! (i use drupal 5.6, php 5.2, mysql 5)

    I made this change

       else {
         $user->roles[DRUPAL_ANONYMOUS_RID] = 'anonymous user';
    +  $GLOBALS['account'] = (array)$user;
       return !empty($user->session) ? $user->session : '';
     function sess_write($key, $value) {
    -  global $user;
    +  global $account, $user;
    +  if (empty($user)) {
    +    $user = (object)$account;
    +  }
       $result = db_query("SELECT sid FROM {sessions} WHERE sid = '%s'", $key);
    WWWW’s picture

    Worked great for both IE and Firefox for me.

    nickistre’s picture

    Added this to my settings.php:
    ini_set('session.auto_start', 0);

    Just piping up to say I hit this "attempt login but just returned back to the page without an error but not logged in" problem in the past couple days on my Drupal 4.7.6 setup after it was working flawlessly for 4 months since Drupal 4.7.4, and the above seemed to have fixed it. I've tried many of the other suggested fixes on this page before this one, though (too many for me to remember...).

    O.S.: Debian 3.1 Linux
    Server: Apache/2.0.54
    PHP: PHP 4.4.4-0.dotdeb.1 (CGI)

    It just seems strange as this was a pretty sudden problem. The only thing I remember doing is telling my VPS host to up my RAM and Hard drive space, but it would seem weird if that triggered it. The Drupal 5.1 setup I have on the same server doesn't have issues with logging in.

    Spacoli’s picture

    I am experienced this bug in Drupal 5 RC. As others have described, site has been running fine for a couple weeks, and all of a sudden I can't login with the Admin (1st) or any other account. Have tried on multiple machines and both IE and FF. I have cleard cache, cookes, etc., and no luck. I have tried a few of the fixes described in this thread, agin no luck. Some of the fixes here are 2.5 years old and most apply to previous versions of Drupal. Some of the fixes reference files that don't exist in 5 RC. So my question is has anyone successfully applied a fix for this in 5? This is driving me crazy, and I find it amazing that the same bug has persisted through 3 years and multiple releases.

    Thanks for any help

    Spacoli’s picture

    Well somehow my problem has been fixed now. I tried a lot of different things, but I believe what fixed it was one of the following steps. I created a new user account by clicking on Create new account link. Then I had a new password sent for the admin account. Logged in from the email link and turned the login module off then on again. I also removed the login link I had added in the secondary navigation menu. Then logged out, and when I tried logging in again the problem was fixed.

    So this doesn't really make sense, but something in that series of steps solved my problem. I would probably guess that it was some kind of conflict with the login block and the login link I added in the navigation.

    Chill35’s picture

    I too have experienced log-in problems JUST on a remote server and JUST with Internet Explorer.
    Using 4.7.4. I keep having to re-log-in.


    deathgod’s picture

    I posted a 5.0 thread for this bug, go to
    in user.module, comment the following code and things should work.
    return 'user/'. $user->uid;
    it should look like this
    //return 'user/'. $user->uid;

    tryit’s picture


    I am installing Drupal for the first time on my p/c. Got everything setup to the point where I tried to create the first admin account. I created the account but tries to e-mail the password. The issue is the e-mail bounces from the ISP.

    Is it possible to create the admin account without - sending e-mail to somewhere ?
    I was able to read the Returned e-mail and tried to use the password sent in it - but am unable to log in i.e it takes me back to the login page.

    I tried to reset the password - but have the same e-mail problem - but I used the URL from rejected e-mail to it took me back to the login page and said Access denied.

    So basically back to square one.

    Any one has any ideas of how make this thing work without sending account names and passwords in the clear to e-mail addresses?


    Jamesh’s picture

    I have been setting up some sites with Drupal 5, using the multi-site capabilities. The problem here was old cookies from previous installs of 4.7 weren't overwritten when connecting to the new sites. The new install tried to use the session id in the old cookies.

    I removed the old cookies from my browser and hit it again. Worked!

    Should Drupal just invalidate the old session and create a new one instead of the described behavior??


    francoud’s picture

    I've have the same problem with a fresh install of Drupal 5 - Windows XP, Mysql, Php5... but I've this problem ONLY with Drupal 5. Older versions - 4.7.4, 4.7.5 - still works perfectly. Strange - the first time I installed Drupal 5, I created the admin user normally, logged in with no problems, started configure it. I also set up a second website with the multisite feature... then I tried from home, and I wasn't able to login anymore. I also tried deleting all files and databases and try it again - but, this time, also the first login was not possible. I can create users, but not log in. Watchdog table simply reports "session opened", no errors at all. The "users" table seems normal (admin user ok, its hashed password seems ok...).

    I tried with different browsers, removing all cookies... nothing worked.


    gabereiser’s picture

    I have done all the suggested fixes and none works.
    PHP 5.0 ISAPI
    MySQL 4.4
    IIS6 w/ IsapiRewrite (this works)
    Windows SBS 2k3
    Drupal 5

    I can login no problem when i'm accessing the server by computer name (http://server/) but not it's public name ( so this only happens to me when trying to login from the public address.

    I have tried everything that I can think of including all of the suggestions and NOTHING works!

    *EDIT* After playing with some settings in the settings.php file. I commented out the..
    if (count(explode('.', $domain)) > 2) {
    #ini_set('session.cookie_domain', $domain);
    part of setting the cookie_domain. Since my sever is both a public and a private server, and runs on multiple ports, setting the cookie domain will keep local users logged in, but public users can't. By removing this, the cookies are global (can be a bad thing).

    This is the only fix I was able to do in order to get public users to log in via a www address. Please Drupal devs, look into this and fix it!

    rafidr’s picture

    i had the same problem with logging in and store viewed page language version in session vars (using Internationalization module) in IE, (FF worked just fine).

    every time i've changed language from default, it was turned back to default

    this fix helped,


    using drupal 5.2,
    php 5.2.1,

    JamesVL’s picture


    We're seeing the same buggy behavior (errors logging in, even on a fresh install) for multiple reasons. The devs aren't hiding anything from "regular users" - this is just a difficult problem to reproduce. If you do have a public server that reproduces this problem, I'm sure they'd love to take a closer look.

    Cookie Issues

    Domain names, forwarding, and which domain your cookie is set for can cause the problem. Fixes involve tweaking your web server setup, the Drupal domain name configuration, and clearing your cookie cache.

    In these instances, you may see different behavior in different browsers - e.g. broken/old cookie lingering in IE while Firefox is freshly hitting the site.

    Main problem: a browser will only send its cookies back to the host they originated from - if you logged in at, your cookie may not be sent back to (But it will be if your login page sent a cookie configured for the entire domain, and not just the sub-domain... sigh.)

    Cookie issues - which indicate your logged in status - can also mess with the symptoms of these other issues.

    Session regenerate_id()

    This fix is probably tied into some kind of cookie issues, but FWIW, commenting our the session_regenerate_id() call will weaken the security of your website.

    I'm not a Drupal dev, but my guess is they use that call to periodically assign a user a new session id and thus make session hijacking attacks exceptionally difficult.

    Objects & Sessions - mainly (only?) in PHP 5.2/Windows

    I documented this one more completely in this bug report:

    Use the test php file attached at that link to see if your web server setup exhibits this behavior - if it does, this is causing the login failure.

    My (further) guess is the exact timing of session_write() and object destruction varies from platform to platform. Thus some users will see this issue crop up in PHP 4.x on Windows, other users will see it crop up in PHP 5.2 on *nix.

    This session/object destruction issue in PHP 5.2 is described here:

    It seems that the patch got rolled into Drupal, and today I installed Drupal 5 on a PHP5.2/Apache2.2.3/MySQL 5.0.21 system (all running on Windows) without a hitch.

    francoud’s picture

    I dont know what exactly MY problem is.. but I investigated a bit. Problem with my server is that my apache server run on port 81
    (not 80). Something's wrong somewhere with this: I restarted Apache on port 80, and I've no more problems with login. I start again my server on port 81, and again cannot login. Now I go and try to understand if it's a Drupal problem, a settings.php/.htaccess problem.. or somewhere else. Since drupal 4.7.5 and older correctly works on port 81 on my same server, I suppose it's not an apache problem (but, who knows...).
    Latest news:

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

    ini_set('session.cookie_domain', '');
    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 new website; 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 found suggestions in:

    Bye :-)

    MFH’s picture

    I have (had?) this(?) problem (with 5.0) in spite of (i.e. after) setting cookie_domain and cookie_path
    for a subsite (first site at domain.tld/xxx , subsite at domain.tld/xxx/yyy,
    with cookie_path's set to /xxx/ resp /xxx/yyy/.)
    I could login (with mozilla) only by using the one-time login link received by mail.

    (seems to be browser dependant, cannot reproduce it with all browsers)

    valderost’s picture

    I ran into this for the first time last night, when I put Drupal onto non-standard port 81. After some poking around with the help of debugging tools (Paros), I found that Drupal is putting port numbers into cookie domains, e.g. "". RFC 2109 makes no provision for including port numbers in cookie domains.

    This is why commenting out the cookie domain lines and hardcoding cookie domain in settings.php solves the problem for some people, myself included.

    Fix the non-compliant cookie, and some of the login problems here will go away.

    Chris Lozinski’s picture

    I have been running Drupal for a couple of years now and only today encountered this problem - on a (dare I admit it) a V4.6 installation and also a V5 installation logging in with Firefox. I could however log in with IE7. I eventually solved the problem by clearing the Authenticated Sessions on Firefox and now all is back to normal!

    Hope this helps someone.


    linuxpimp’s picture

    From home it works flawlessly. From the office via a http proxy i have this issue.I log in and am returned to the login page, didn't 'take'.

    Now here's the interesting part: I close my browser, firefox in this case and reopen it, and i'm logged into my site when i go back to the URL..

    The plot thickens..


    wireless router reviews

    der_sensemann’s picture

    thx Chisel,

    I had the same problem just today while my multisite worked fine last years ( & last days).
    After re-install didn't help I tried IE 7 which worked, but Firefox didn't get back to normal before I cleared the Authenticated Sessions.

    Hope it won't reoccure every day, for with 4.7 I didn't have the problem.



    Chris Lozinski’s picture

    I have just completed another update on a site going from 4.6.x to 4.7.6 and the testuser can't access the site via IE7 though is shown as logged on in the 'Who's on line' block! Had all sorts of problems till I just emptied the cookies from IE7 and 'Bob's-Your-Uncle'! Alls well again. Mmm very interesting! I think I will have to post these tips on all my sites so users don't give up in despair until Drupal Central can come up with an answer.



    citricguy’s picture

    Remember to test by disabling Mods.

    I solved this problem by disabling the Global Redirect module.

    I am running Drupal 5.1

    Good luck!

    (Oh and I think this thread is so long because this error can be caused by a lot of things.)

    pauldreed’s picture

    I had the same problem which started when I installed Global Redirect - couldnt log-in.
    But strangely could log-in if I went to my forum and logged in where it says 'login or register to post'.

    I eventually disabled Global Redirect and all is well!!

    greenhouse’s picture

    I've been struggling to get CivicSpace installed for days now, and finally pulled it off (had to edit lots of files manually due to my host placing the MySQL database on a different machine than the rest of my site).

    Anyway, I'm having the same login problem now. I tried a couple of the various fixes mentioned here, but none worked, and I'm not sure which would be most appropriate for this version of CivicSpace anyway. Running IE 6.0; haven't tried other browsers yet.

    Any help would be highly appreciated!

    Oceria’s picture

    As for a lot of people the solution offered in this comment only gives resolution for about half of the people I have been reading in. It seems most people having trouble work with php 5.x, most of them 5.2.0 to be exact.
    And indeed since my ISP moved from 4.4 tot 5.2.0 the problems started for me. It seems php 5.x is indeed a bit messy when it comes to global variables. However if I am not mistaken they addressed this problem in the new 5.2.1 release. I do not have the possability to upgrade myself, but is there anyone that can test this?

    Oceria doesn't know where this -repeatbutton -repeatbutton is....

    alias420’s picture

    I tested out php 5.2.1 to see if these weird session issues would be taken care off, but no dice. 5.2.1 still the same problems as 5.2.0

    My fix that worked for drupal 4.6.x on php 5.2.x was to insert the following line into the sess_read() located in right after the global $user declaration at the beginning:


    I found the above fix @ . I later came across this post which says you can just insert the same line into your settings.php. I haven't tried this route myself but in hindsight it looks a little cleaner.

    I had previously used the $GLOBAL['tempUser'] = $user; in my index.php as a fix to login on drupal 4.6.x sites running on php 5.2.x. This worked for logging into the site but any POSTs sent by a form would log me out again.

    Using the mysqli:// fix in my settings.php for 4.7.x & 5.x sites worked great with no problems.

    cgjohnson’s picture

    I too am having this problem; it has been working fine for weeks, and today I created a new user with special role (admin) slightly more limited than user 1. When I tried to login using this info, I get the site maintenance page (I've got my site offline) and cannot login.

    No error message, nothing. Can't get login screen to login as first user again does nothing.
    I'm on a mac os x using firefox 2.0
    drupal 4.7

    I tried:
    1. clear cache, clear cookies, clear privacy, restart Firefox
    2. add to settings.php
    ini_set('session.cookie_domain', 'exampleorg');

    ini_set('session.auto_start', 0); no avail.

    Can someone help me? many MANY thanks. this is a bummer, otherwise my first experience creating (but not administering) a drupal website was grand till now.

    cgjohnson’s picture

    I now think I've tried all the suggested fixes one at a time in this long thread. I'm getting scared -- still can't login to the site! Is there a fix for a relative newbie (I don't want to do too much hacking)? Anyone who can help?


    mslowik’s picture

    Session logged in as user 1, so I can see the logs and in another browser trying to login as another user. The log shows:

    user | 2007-03-05 11:13 | Session opened for testuser. | testuser

    However I still remained logged out.

    The problem in my case was difference in settings.php file. This issue report pointed me in right direction. I commented out the following code (btw - this code did not exist in 4.6 version) and everything is back to normal :)

     * 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.
    /* 05-03-2007 Cannot login therefore commenting this out:
    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);

    In my case this is a intranet webpage so I did not bother about cookie domain. It may need editing these settings if it is an external website or multidomain environment (just a guess). However this is probably the place to look in order to fix the problem with log in :)

    Hope this helps someone.


    tormu’s picture

    Just tried figuring out what is the problem, tried commenting out stuff in the user.module and clearing caches and so on, but it was this same thing. Running brand new Drupal 5.1 on intranet server, so the root address for this installation is - I guess the port number can mix things up also..

    BarisW’s picture

    After searching a long time I found a/the solution. I have 5.2.0 on Linux. I was able to login with Firefox, but not with Internet Explorer and Opera. When I tried to login using IE/Opera the page refreshed after I clicked submit and the submitted data (even unencrypted password!) was placed in the querystring. So the browser does a GET instead of a POST. This orrured with ANY post, not only the login form. Even contact-forms or CCK-forms.

    I solved it by enlarging the upload size limits of the webserver (Apache). This can be done in PHP.ini, or with a .htaccess file. I fixed it using htaccess with the following two lines:

    php_value post_max_size 16M
    php_value upload_max_filesize 5M

    Probably the content of the form (even text-only!) was larger than the default setting of the webserver and that caused the login-problem.
    I hope this helps others!

    Baris Wanschers (@BarisW)
    Drupal specialist

    ciscokid’s picture

    have been having same problems as many. have 4 previous Drupals running with no probs but this one ahhh. nearly cost me my marriage (only 5 days old :-)

    My problem was that the settings.php file in folder \sites\default was all messed up (dont know why??) and cookie lifetimes etc were all wrong. I just pasted original values in from unzipped version and IT WORKED. They should be something like:-

    ini_set('arg_separator.output', '&');
    ini_set('magic_quotes_runtime', 0);
    ini_set('magic_quotes_sybase', 0);
    ini_set('session.cache_expire', 200000);
    ini_set('session.cache_limiter', 'none');
    ini_set('session.cookie_lifetime', 2000000);
    ini_set('session.gc_maxlifetime', 200000);
    ini_set('session.save_handler', 'user');
    ini_set('session.use_only_cookies', 1);
    ini_set('session.use_trans_sid', 0);
    ini_set('url_rewriter.tags', '');

    I think on my original set up of Drupal last year I had to change the session lifetime to 1 or something similar as explorer will stay logged on to site even if it is closed down and reopened or similar (but that is a different story!)

    Hope this helps
    the kid

    morningbird’s picture

    I've tried the fixes above with no luck. Here's what happens in more detail:

    I try to log in and nothing seems to happen, but my username shows up on the currently logged in list. Further, if I try it a few times, I get duplicates of the username in the currently online list. If I click on my username to look at my profile I get this error:

    warning: Invalid argument supplied for foreach() in /modules/user/user.module on line 1506.

    I took a peak and it is unfortunately not neat and tidy enough for this newbie to figure out which line is 1506.

    If I put in the wrong password, I get the appropriate message.

    When I try to create a new account I get a HUGE mess of errors that look like this:

    warning: Cannot use a scalar value as an array in /includes/ on line 764.
    warning: Cannot use a scalar value as an array in /includes/ on line 765.
    warning: Cannot use a scalar value as an array in /includes/ on line 768.
    warning: Cannot use a scalar value as an array in /includes/ on line 779.
    warning: Cannot use a scalar value as an array in /includes/ on line 784.
    warning: Cannot use a scalar value as an array in /includes/ on line 635.
    warning: Cannot use a scalar value as an array in /includes/ on line 759.
    warning: Cannot use a scalar value as an array in /includes/ on line 764.
    warning: Cannot use a scalar value as an array in /includes/ on line 765.
    warning: Cannot use a scalar value as an array in /includes/ on line 768.
    warning: Cannot use a scalar value as an array in /includes/ on line 779.
    warning: Cannot use a scalar value as an array in /includes/ on line 784.
    warning: Cannot use a scalar value as an array in /includes/ on line 790.
    warning: uasort() [function.uasort]: The argument should be an array in /includes/ on line 2119.
    warning: Cannot use a scalar value as an array in /includes/ on line 2150.
    warning: Cannot use a scalar value as an array in /includes/ on line 2161.

    I would love to see if my logs have anything else to say, but I can't get log in to look at them at the moment.

    It has been working just fine for me for 12 weeks. I haven't made any module or theme changes in several weeks. I just added a new user with some special permissions a few days ago. All other users have read-only privaleges.

    I was able to log in with Firefox, but I got the same errors as above.

    tarmo181’s picture

    I have Drupal 5.1 at linux, apache server.
    I was not able to log in using either FF, Opera or IE. No error messages, just the same old login screen.

    I changed php_value session.auto_start value from .htaccess from 0 to 1 and now I am able to log in again.

    Hope it helps someone.

    cwildermuth’s picture

    I tried a bunch of things here and nothing worked. This was on a brand new install of Drupal 5.1 on a box where other Drupal 5.1 sites were working fine.

    I cleared my browser cache and everything works great now!

    There must have been a corrupt session cookie or something??

    The new site was accessible via a sub domain where another Drupal 5.1 site was installed; Does Drupal use session cookies based on the domain name? Is it possible that because I was logged into the working Drupal 5.1 website that I could not login to the Drupal installation on the sub domain?

    linuxpimp’s picture

    What i find very interesting is that i have log-in issues 99% of the time using Firefox, yet using Epiphany Web Browser (on the same box) it logs in first time, every time....


    squaretone’s picture

    If you are running php 5.2 you may have the problem where the uid in the session table gets reset to 0 after a successfull login. this give the appearance of logging in fine but the next link you click on you seem logged out again.

    check out for a one line fix to that.

    Eric Lawrence
    Developer/UX Designer

    oberkom’s picture

    I could solve this issue setting avoiding session_regenerate_id(); function at sess_regenerate() in this way:

     * Called when an anonymous user becomes authenticated or vice-versa.
    function sess_regenerate() {
      $old_session_id = session_id();
      // We code around by destroying
      // the session cookie by setting expiration in the past (a negative
      // value).  This issue only arises in PHP versions before 4.4.0,
      // regardless of the Drupal configuration.
      // TODO: remove this when we require at least PHP 4.4.0
      if (isset($_COOKIE[session_name()])) {
        setcookie(session_name(), '', time() - 42000, '/');
      /* from here ------------------------------------------------------------------------------- */
      global $user;
      if ($user)  {
        print 'document.location.href = "/user/' . $user -> uid  . '"; ';
      /* to here -------------------------------------------------------------------------------  */
      db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);
    Jack_Sparrow’s picture

    Drupal 5.1
    Windows XP
    Windows Server 2000
    FireFox 2 & IE 7

    Try commenting out user.module at line 957:

    return 'user/'. $user->uid;

    Not too sure of the consequences of this, but it at least works for me.

    Trust this helps.