4.7 beta 6 login problems, additional confirmation

On my HEAD site, uid 1 cannot login via login page or login block, but can login via the one-time login e-mail link.

None of my HEAD sites are allowing any uid to login (except for e-mailed one-time logins); previous working revision of the user module is 1.596

http://cvs.drupal.org/viewcvs/drupal/drupal/modules/user.module?r1=1.596...

This patch on head made it work for me.

I found I could also resolve the issue by clearing my cookies and truncating the sessions table. Why that is, I don't know.

i've just installed a fresh, clean 4.7b6 installation in my standard development environment (debian/sarge, apache 1.3, mysql 4.0, php 4.3.10), and unfortunately could *not* reproduce this error, which leads me to believe there may be something specific to the hosting environment of others who are experiencing this, or that they are doing something to the config after first login that produces the bug.

i literally setup the site, registered a first user, reset my password, and then logged out. logging in worked as expected, right off the bat. can someone give some more details on how they are producing this bug, so that we can start to narrow down where this is coming from?

After a fresh install of drupal HEAD, if I create the first account and then logout, I cannot log back in. If I login via one-time password email, go to admin/settings and save it, the site allows me to logout and log back in normally -- so far. Saving the settings also seemed to help my pre-existing head sites.

mfb-

Here's some background info on Drupal login, FYI.

When a new visitor hits a Drupal-powered site, the session.inc file instantiates a new session_start() to set a PHPSEESID cookie. This value is stored in the Drupal database in the session table in order to allow users to maintain sessions across multiple servers. (Since session handling is stored in the database.)

Anonymous users go into the session table with SID = session_id() and uid = 0.

As a result, only PHPSESSID is cookied by Drupal. The system looks up a user's login status based on that session id. See session.inc sess_read() and sess_write().

The session.inc file also runs a check to make sure that session_start() is only invoked once-per-user.

Drupal's login mechanism sets the session_id() to the sid column in the sessions table. When a user hits the site, this table is checked against the PHPSESSID cookie held by the user.

-- That's why you have to clear your cookies and the Session table.

You might also check to see that this bug [http://drupal.org/node/46591] hasn't somehow re-emerged.

faced the same problem in IE but not in firefox or opera. I have number of sites on 4.6.6 and 4.7 but i faced problem on 2 sites not all.

Additional Info: I installed Drupal 4.7B6 on 3 sites and all of them worked perfectly. No problems at all.

But after upgrading another site to Drupal 4.6.6, an user could not login anymore. Then she created another login and logged in, later she logged out out and tried again with her original username and finally logged in.

I believe this problem came up only in Drupal 4.7.b6 (as others reported) and Drupal 4.6.6.

I am marking this won't fix -- it seems there is nothing Drupal could do. If we canI get more reports with stable reproducability, then this will reopen.

The problem seems to re-occur. As in, I login to all my HEAD sites ok after clearing sessions table, clearing cookies, re-submitting module and settings pages. Sleep on it. In the morning, I cannot login.

I will say that I have 5 head sites in subdirectories on the same domain; these apparently are sharing the same cookie since the path is set to "/" ?

Have you tried setting the cookie domain to subdomain.domain.com (rather than empty)?

...or using a different session.name for each site?

I have found how to reproduce the problem. The sites on our main server set cookies with domain .example.com; the head sites I am having trouble with are on a different server and set cookies for dev.example.com

If I clear my browser cookies and first go to the main server, I get the .example.com and this cookie seems to now have precedence over the dev.example.com cookie; both are presumably being sent to the drupal site but drupal seems to be ignoring the correct cookie: I cannot login to the head sites. I can log in to a 4.6.5 site on the dev server, or an older head site on the dev server.

Now if I clear cookies and first go the head sites and later the main sites, I can still login fine.

This is a new issue, caused by the new session_regenerate_id() and the db_query below it in user.module.

The only work around aside from commenting out these lines is to move the dev sites to a different domain.

(or the patch above seems to help, although I'm not sure what it means from session security perspective)

If you found that patch useful, what about this one?

Changing the session.name in php.ini also resolves the issue. Such that we have .example.com cookies with one name and dev.example.com cookies with another name.

It should probably be documented somewhere that this is now required. Also I'm curious to know why this is the case.

chx: that patch works as well, but only if I deleted the session_start() line, which caused:

Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) in /usr/local/www/data/drupal/modules/user.module on line 926

(It did log me in, but threw that error message).

If you've got drupal session cookies set for both .example.com and host.example.com, but they don't share Drupal databases, and your browser can't decide which cookie is more relevant.. of course you will have problems.

It seems like you should change the .example.com to set cookies for a specific hostname instead of the entire domain, unless you are really going to share sessions across Drupal sites on different hosts in that domain.

Not sure that regenerating a new session id on login is exactly the right thing to do for a case that seems like more of a server configuration problem.

It's odd that this only became an issue with the recent patch to user.module, adding session_regenerate_id(). I'd be interested to know exactly what is happening. The easiest server-config workaround is to change session.name so the session cookies have different names.

Not sure that regenerating a new session id on login is exactly the right thing to do for a case that seems like more of a server configuration problem.

session_regenerate_id is necessary to protect you from "session fixation" attacks.

Do any of the following issues help here?
http://drupal.org/node/56634 (using by mod_rewrite)
http://drupal.org/node/56357 (about configuration of cookies)

Is this a problem in HEAD or was just only in 4.7.x?

I upgraded from drupal 4.6.6 to 4.7.3 and now , users are not able to login at all, there are no errors, just the screen keeps coming back.

I am stuck... can someone please help

@taherk: did you clear sessions table? Also, ask your users to clear cookies.

Closing, over a year with no response..

We're "probabaly" in an ok situation login wise now...