After installing Drupal, I cannot login anymore after logging out for the first time. That is to say, after typing username and password and hitting enter, the screen refreshes and I seem not to have logged in. I do not get any error messages about using wrong names etc...

After searching the forums I have also concluded that my login problem is NOT related to:

  • the double login phenomenon
  • cookies
  • cache

However, the following hack allows me to login normally. The hack consists of commenting out three lines in user.module:

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

This leads me to believe that the real cause of the problem lies with the PHP settings on the server of my webhost. My questions are:

What am I potentially compromising by commenting those lines out in user.module?
What other solutions are there?

Thanks,
Kdebaas

Drupal 4.7.4, PHP 5.1.6, IIS 5, mysql client api 5.0.22
Using browsers: Firefox 2 and IE 6
Installing Drupal 5 also didn't get me past the login screen...

Comments

kdebaas’s picture

kdebaas commented

Found the answer to: What am I potentially compromising by commenting those lines out in user.module?

http://drupal.org/node/53838#comment-136923">session_regenerate_id() & security
Heine - July 14, 2006 - 08:09

session_regenerate_id is a php function that generates a new session id to prevent session fixation attacks [PDF].

I would still like to know if there is any other way to solve the login problem.
Thanks
Kdebaas

kdebaas’s picture

kdebaas commented
Title: Not able to login after logout, until lines in user.module are commented out. » Not able to login after logout
Version: 4.7.4 » 5.0-beta2

I am pulling out my hairs over this. I have installed 4.7.4, 5.0-beta1, and 5.0-beta2. Still the same problem. I have installed them on a lamp-server at home, and lo and behold, that works...

So here goes, once again, into the breach:

At www.parallelports.org/dev I have Drupal 5.0-beta2 running on IIS 5, PHP 5.1.6, MySQL database 4.1.21, no MySQLi support. Also, incidentally, no support for sending emails from the server as yet. phpinfo() can be found at this adress.

There is a uid=1 account, and a authenticated account: user="testuser" pass="test".

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

It was my understanding that session_regenerate_id(); in function sess_regenerate() in session.inc, would recreate the cookie with the new session id. But it doesn't. Incidentally, as in first post, commenting out session_regenerate_id(); does enable me to log in, but that is hardly satisfactory.

Please, I am in need of some community plumbing here. I know login issues are to be found in many places on the forum, or within the issues pages, but I am having a hard time keeping unrelated items apart in the sometimes very long listings. Take this as a fresh start...

Thanks in advance
Klaas

RobRoy’s picture

RobRoy commented

Are you sure IIS is actually writing session info to disk? Check your PHP.ini for session.save_path and make sure that a new file is created for your session, not just a record in the db. We had a similar problem in IIS and putting the right directory there and/or fixing the file permissions fixed the problem.

kdebaas’s picture

kdebaas commented

Thanks for your followup.

There is no session.save_path defined in php.ini. However, as Drupal sets session.save_handler to user in settings.php, it is my understanding that this bypasses the need for a session.save_path.

From link:

Isn't the 'session.save_path' directive unnecessary and misleading? Because Drupal uses session.save_handler = user (our sessions are
stored in the database), that option won't do anything. AFAIK,
save_path only matters when using save_handler = files.

Correct me if I am wrong on that though. I did try and set session.save_path with ini_set in settings.php to a number of directories, all to no avail... (One of the directories being the files directory, to which I know I have permissions)

Any other thoughts?
Klaas

AstaC’s picture

AstaC commented
Component: base system » user.module

Hm - not sure I'm writing this in the right place. I however have exactly the same problem. But I can not find those lines in user module for 5.0 beta2?

kdebaas’s picture

kdebaas commented

In Drupal 5.0beta2 or later, look for and uncomment sess_regenerate.

I am not sure if it is really wise to do so, and it definitively is not a "real" solution. I have left this issue for a while, and have been working with a Drupal install on a linux-apache server for the moment. I hope I can get back on this issue later, and try to solve this problem which seems to me to be related to the IIS environment I am working in.

AstaC’s picture

AstaC commented

My installation is on apache-linux but still doesn't work.

Gman’s picture

Gman commented

I am getting this issue too, as noted in http://drupal.org/node/98108.

I am only getting this error on PHP 5.1.6, with IE7. FF2 has no problems, and when running on PHP 5.1.4 I have no problems, so I believe this error can be localized to Drupal 5 while running on PHP 5.1.6. We have a bunch of Drupal 4.7 sites running on the PHP5.1.6 server and we are a little worried about degrading back to 5.1.4 to make our Drupal 5 sites run.

Thanks, Greg.

kdebaas’s picture

kdebaas commented
Status: Active » Closed (fixed)

I have since moved on to an Apache server, and don't even have access to that IIS server for debugging now. Closing the issue. Open a new one if you have problems with login.