By cmsproducer on

I am working on a project in which some browsers (mainly IE) and some safari & FF are not able to go beyond the login screen. After a login attempt (properly recorded by watchdog), the login page remains without an error message (detailed in bugs http://drupal.org/node/60584 and http://drupal.org/node/53838). I am not creating a duplicate, but I am trying a number of fixes and I need to test on a very large number of configurations.

Request:
Please login and logout, and then try to login again to these two Drupal 4.66 and drupal 4.7 installations and if you run into the problem I have detailed, please drop me a note at: http://www.cmsproducer.com/feedback (you do not have to give your contact info - just tell me if it worked for you).

Test Urls:
http://www.phovi.tv/
http://www.phovi.tv/47/

In each case, please login as:
demo
both for username and pw

Thanks for the help.

⋅ Categories: Drupal 4.6.x, Drupal 4.7.x

Comments

beginner’s picture

beginner commented

I have no problem login/logout with Konqueror, as long as I stick to one site. If I go from one site (4.6) to the other (4.7) my cookie for the one will affect the one for the other, but this is a known issue. I think there is a fix for that already: I think you have to change the default cookie name.

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

gdip’s picture

gdip commented

No problem on either site.

BlackSash’s picture

BlackSash commented

Works for me ™
No problems logging in here, on FF 1.5.0.3 and IE6-and-a-bit.

-------------------------------
GU d- -p+ c++++ l++ e* m* s+ n+ h+ f? g+ w+++ t- r y?
Madcap - design - development - consultancy
http://www.madcap.nl - Running on Drupal, of course.

cmsproducer’s picture

cmsproducer commented

Thank you for your help in testing this issue, I was able to find the solution and here it is:

The problem is obviously caused by an anonymous cookie string being used int he logged in session. To solve the problem of Drupal not logging in and not giving an error message, in the user.module file in the modules directory, edit the lines 947 - 954 in the user.module of 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

Heine’s picture

Heine commented

Odd, because user.module actually does something similar, but then in the submit hook:

function user_login_submit($form_id, $form_values) {
  global $user;
  if ($user->uid) {
    // more code
    $old_session_id = session_id();
    session_regenerate_id();
    db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);
  }
}

Haven't looked in detail (can't reproduce the login problem) why result differs from your solution.

edited to add (took some searching): you may also want to take a look at http://drupal.org/node/60584#comment-93095
--
When your problem is solved, please post a follow-up to the thread you started.

cmsproducer’s picture

cmsproducer commented

True, I observed that the three lines before where I suggest recreating the session are meant to refresht he session information. However, I found that the same session cookie ID was being maintained before and after logging in. Being that the manual solution to the problem is to delete cookies, my reasoning is that if I set the system to delete the session ID at the end of the anonymous session (the moment just before the logged-in session is created), it will prevent the old cookie ifnormation from hindering a proper login. I commented the three-lines that Drupal has that regenrate the session ID.

I am yet to understand why the similar code you pointed out does nto prevent the problem from happening in the first place. I thought that since the problem existed in Drupal 4.66, it should have been fixed in 4.7, but I had a deadline with a client and so I implemented a solutiont hat works without paying too much attention to why user.module does nto work as it is.

If you find a better solution, I am interested in understanding why user.module has that issue despite code to create a new session on log-on

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