Problem with login (doesn't seem to 'take')

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.

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"

--- www.harvesterchurch.org

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.

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.

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 http://phplens.com/phpeverywhere/node/view/12

cheers,
Otto

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

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 Drupal.org 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 `http://vokation.com` 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.

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.

--
Axel,
Russian Drupal Community

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?

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.

WEIRD !

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.

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.

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 database.mysqli.inc 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/database.inc, I changed:

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

to:

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;
  $connections++;
  if ($connections > 5) {
  	static $connections = 0;
  	$db_conns[$name] = NULL;
  }

And:

function db_query($query) {
  

to:

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. 
  db_set_active();

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

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 Jason@gut.sourceforge.net (see drupal.org/node/3884)

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.

Tony

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!

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/session.inc 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/session.inc 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.

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:
http://www.freeq80.com

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.

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.

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

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?

Thanks!

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

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

I think this issue http://drupal.org/node/60584 may have something to do with it.

Rob
------------------
Some of my Drupal sites:
Quotes | MySpace Layouts

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();
session_regenerate_id();
db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);

TO this:

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

And That´s it

I am Using:
DRUPAL 4.7
APACHE
PHP 4.3

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

SESSIONID
61ciq55i7mmuv4vo2j36lb5si00tfimm
agencysolutions.us/
1024
3102474496
29786799
503954672
29782143
*

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 www.agencysolutions.us in deekayen@www.agencysolutions[1].txt:

SESSIONID
5l3dcgecfsthlkn6pj18au4sn32h8at6
www.agencysolutions.us/
1024
1707507200
29786800
3403324672
29782143
*

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  ncysolutions.us.
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 http://www.agencysolutions.us/admin, 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 common.inc, 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} !^www.agencysolutions.us [NC]
  RewriteRule ^/?(.*) http://www.agencysolutions.us/$1 [R=permanent,L]

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?

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!

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

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.

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 www.oursite.com, but then, of course, the cookie wouldn't transfer over to oursite.com (sans WWW). So, I modified the htaccess to force the oursite.com (without the WWW), and the problem seems, for the moment, to have gone away.

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 http://www.faib.org/user ), 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 http://www.faib.org/ ), 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.

Cheers,

Tomas

------
Tomas J. Fulopp
http://www.vacilando.org

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 :)

Granville
Kirkham Systems

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

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

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

Rotem.

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 mydomain.com's home directory is /home and the drupal site is in /home/reunion/ with the URL mydomain.com/reunion, create a subdomain reunion.mydomain.com 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.

After a good research session and looking for a solution on Drupal.org, 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

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 drupal.org forums and bug postings and found this thread. I tried many options, but none of them worked until I found this patch: http://drupal.org/node/61368#comment-94973 (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.

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 drupal.org forums and bug postings and found this thread. I tried many options, but none of them worked until I found this patch: http://drupal.org/node/61368#comment-94973 (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.

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

http://www.guyanagateway.org.gy

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.

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

If you can say how to reproduce, post there:
http://drupal.org/node/61900

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.

--
http://www.reuniting.info/
Healing with Sexual Relationships.
http://www.wechange.org/
We live in a world of solutions.

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?

Have a look at this:

http://drupal.org/node/53838#comment-136510

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

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

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

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

to

ini_set('session.cookie_lifetime', 0);

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

www.johnstonwebsolutions.com/we_install_modify_and_maintain_drupal_web_s...

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, www.artivocali.org, 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 www.artivocali.org, but access the server imediately.

I noticed that firefox displays the url to which the www.artivocali.org is forwarded, and IE does not. It keeps displaying http://www.artivocali.org

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.

http://forums.oracle.com/forums/click.jspa?searchID=-1&messageID=1138452

Another one:
http://www.phpfreaks.com/forums/index.php?topic=102792.msg410443

Can anyone turn this into a global drupal solution?

Thanks

When logging in through the block, it redirects me to the root http://domain.com. If I started there, I am logged in. However, if I started at http://www.domain.com, I get redirected to http://domain.com and it appears that I am not logged in. If I go back to http://www.domain.com, 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).

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/drupal.mayapur.com/html/modules/user.module on line 244.

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

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

Joe Murray

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

I hope this helps someone out there.

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
http://renseri.net (joomla)
http://foreldrekontakten.com/nasjonalt (My first step with Drupal)

Description

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?

Tried:
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 cinare.net/jose.

José

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

http://drupal.org/node/92802

===============
Jim Ruberto
Xerosphere
jim@xerosphere.net

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. :-)
Herb

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.

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.

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

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

drupal_page_footer();
$GLOBALS['tempUser'] = $user;.

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

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...

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

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.

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:
session_regenerate_id();

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

Added this to my settings.php:
ini_set('session.cookie_domain','www.mydomainhere.com');
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 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

Hi,

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?

Thanks,
Tryit

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??

~james

Summary

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 www.example.com, your cookie may not be sent back to example.com. (But it will be if your login page sent a cookie configured for the entire example.com 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: http://drupal.org/node/61900#comment-136378

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: http://drupal.org/node/92802

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.

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.
Regards

Chisel

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.)

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!

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....

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 http://drupal.org/node/108663 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.

Regards,
Michael

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!

Hi
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

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/form.inc on line 764.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 765.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 768.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 779.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 784.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 635.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 759.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 764.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 765.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 768.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 779.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 784.
warning: Cannot use a scalar value as an array in /includes/form.inc on line 790.
warning: uasort() [function.uasort]: The argument should be an array in /includes/common.inc on line 2119.
warning: Cannot use a scalar value as an array in /includes/common.inc on line 2150.
warning: Cannot use a scalar value as an array in /includes/common.inc 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.

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

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.

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?

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 http://drupal.org/node/102114 for a one line fix to that.

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

/**
 * Called when an anonymous user becomes authenticated or vice-versa.
 */
function sess_regenerate() {
  $old_session_id = session_id();

  // We code around http://bugs.php.net/bug.php?id=32802 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 '<script>document.location.href = "/user/' . $user -> uid  . '"; </script>';
  }
  exit();
  /* to here -------------------------------------------------------------------------------  */
  session_regenerate_id();

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