destroy session cookie to prevent multiple domain cookies on session_regenerate

hmm... I think this problem can be solved by choosing a different session_name for each site as described here:
http://drupal.org/node/56357

or here:
http://www.phpmix.org/setting_up_php_sessions/setting_up_session_cookies

Sorry, but I fail to see how this patch can work.

+    // destroy the cookie on the client to prevent the existence of two domain cookies
+    if (isset($_COOKIE[session_name()])) {
+      setcookie(session_name(), '', time()-42000, '/');
+    }
     session_regenerate_id();

Note that setcookie doesn't sent anything to the browser. It just tells PHP to send a cookie along the headers of the next request.

However, session_regenerate_id updates the session cookie too. Hence, invalidates whatever setcookie(session_name() ...).

However, session_regenerate_id updates the session cookie too. Hence, invalidates whatever setcookie(session_name() ...).

I think that's the point, in PHP 4.3.2 session_regenerate_id doesn't update the session cookie.
This patch doesn't work for me though. I guess the cookie doesn't get set..? I have tried a few fixes; nothing works except commenting out the regeneration code, but that's a huge security risk.

Sure, quoted from the PHP manual:

4.3.3 | Since then, if session cookies are enabled, use of session_regenerate_id() will also submit a new session cookie with the new session id.

However... from the file INSTALL.txt in 4.7:

Drupal requires a web server, PHP4 (4.3.3 or greater) or PHP5
(http://www.php.net/) and either MySQL (http://www.mysql.com/)
or PostgreSQL (http://www.postgresql.org/). Your database user
will also need sufficient privileges to run Drupal. Please
check the INSTALL.mysql.txt and INSTALL.pgsql.txt for more
detailed information.

INSTALL.txt in 4.6.3:

Drupal requires a web server, PHP4 (4.3.3 or greater) or PHP5
(http://www.php.net/) and either MySQL (http://www.mysql.com/)
or PostgreSQL (http://www.postgresql.org/).

I don't know for earlier versions.

If it needs to get in, then it might need some kind of PHP version checking.

4.7 does not need this as it will break with anything below 4.3.3 anyways Delegating to 4.6. (BTW do you know how old 4.3.2 is??)

chx, is it possible that Drupal 4.6.6 also requires PHP 4.3.3?

crunchywelch, is it possible that the problem is caused by something else?

Looking at the PHP code itself, and the evolution of the session_regenerate_id function, it looks like there have been changes, but as far as I can see the internal function php_session_reset_id is called always (which is the one that does the cookie stuff).

In this level, the PHP code doesn't have aparent differences between linux distributions, so I think if this works for PHP 4.4.0 on RedHat, it also works for PHP 4.4.0 on SuSE.

Maybe this solution breaks other things. As per the following note in the manual, PHP would send several Set-Cookie headers:
http://www.php.net/manual/en/function.session-regenerate-id.php#53480

I think we would need to identify what happens and when it happens, exactly, before doing something like this.

Another approach would to use a custom version of session_regenerate_id, such as the one posted here:
http://www.php.net/manual/en/function.session-regenerate-id.php#45124

I agree with Markus. Figuring out what exactly goes wrong seems to be mandatory before we can proceed. Looking at the code, and reading the PHP docs, this shouldn't be allowed to happen...

The issue is that some browsers do not discard the intial domain session cookie when presented with the new one.

If this is the problem, then we can do whatever but we won't be able to fix as this indicates that a) by design, a new value is sent b) some buggy browsers keep the old alongside the new. How are we supposed to fix this?? I go and Google.

I've found something that we might need to add, when PHP is lower than 4.4.0 (or >5.0 and <5.0.5 or >5.1 and <5.1.0).

This is the bug in PHP:
http://bugs.php.net/bug.php?id=32802

Fixed in 4.4.0, 5.0.5 and 5.1.0 branches:
http://www.php.net/ChangeLog-4.php
http://www.php.net/ChangeLog-5.php

At least, menalto Gallery2 did it:
Find function fixCookieVars here

crunchywelch: maybe it depends on the PHP version and if there are cookie paths involved here? could you please check the cookie settings using in the websites you have encountered this problem?

Oops, someone has been eating part of my post!

The link to the PHP bug:
http://bugs.php.net/bug.php?id=32802

It would be helpful to test if the fixcookievars routine fixes the issue for crunchywelch. If this is the case, he could run it in settings.php, I think.

Haven't been following this issue, but i'd like to point out that 4.6.x requires PHP 4.3.3 already. This has been so since 4.6.0 due to search.module. 4.5.x is not being maintained for bugfixes like this.

Having read the PHP bug report, we essentially have two choices:

• Include a version of the fixCookieVars() function which rebuilds $_COOKIE from the raw headers.
• or Include a hack to fix only our own cookie.

I'm leaning towards the second one. Session management in Drupal is centralized, and the cookie is only used for the session ID. Modules should not be using their own cookies, but the session system.

fixCookieVars() would add a lot of overhead with almost no benefit. Let's fix it with minimal fuss.

While this is not identical to others' problems, it may help someone searching for help.

session_regenerate_id() was not writing the new session id to the client using IIS 5 / CGI + PHP 5.1.2. None of the fixes above (fixCookieVars(), narrowing cookie scope, changing cookie name) solved the issue. The only fixes that worked were removing the session_regenerate_id() call in user.module (security degradation) or changing IIS to use ISAPI instead of CGI.

There is a post here http://drupal.org/node/6696 where users are having login troubles with IE and not FF. I had the same problem and cleared the cookies in IE and it worked. This is on a clean DRUPAL-4-7 install.

Any status on a revised patch for this? Or, any other info I can provide?

I have a live Drupal 4.6 site with the "IE login does not take" problem and all of the system administrators and users get thrown back to the login page when they log in unless they use FF.

I'm about the install ethereal to see that the "double cookie" problem is indeed what's causing this, but "double cookie" is the only bug that's causing all and only the symptoms reported by users.

And just commenting out the session regenerate code, without knowing why this would fix the problem, does sound a little like "brain surgery self taught."

So I'm hoping the real application developers have a fix on this one.

+1 on the patch. i understand the need to know just what is causing the problem, but meanwhile, 4.6.6 is no good without this patch. copernicus didn't know why the earth went around the sun, he just observed it... ;)

Hey everyone,

This is going to be a long post. :)

I've recently stumbled onto this bug myself. My situation is as follows:
* Two live sites sharing the same database. They must share sessions so a user can transparently move through both sites. Thus I had to add a line to each site settings file: session.cookie_domain = "example.com".
* Two dev sites replicating the sites above. The line in the site settings file is: session.cookie_domain = "dev.example.com".

If I clear my cookies and only use the live site OR the dev site, I have no problems. Once I cross over I can only log into the live site. The dev site doesn't login.

Here is what I believe is happening. The browser (in this case Mozilla) spits the example.com cookie back to the code instead of the dev.example.com cookie. I've tested this by using the site and checking the values in the sessions table.

The patch given earlier in this issue may fix the problem for that person's case, but unfortunately it removes a cookie for a site in the parent domain. This is unacceptable as a solution to cover all bases, which is a requirement for core patches.

I will see what I can come up with as a solution. The biggest problem here is the browser determines which cookie to send back and by nature, it'll default to the most-parent domain it can. There must be a fix for it, but given that i've never tackled a problem like this, it may take a little time.

That's all from me atm.

--
Sammy Spets
Synerger Pty Ltd
http://www.synerger.com

I've been examining the bug. Here is the lowdown.

The bug i'm getting is caused by PHP giving preference to cookies (with the same name) having a less specific domain (or in other words, more towards the top-level domain). This was reported to PHP developers with bug report and the bug was fixed in May 2005. It seems something has gone wrong with the code (at least in my system) and this patch was never applied or it was reversed either accidentally or for some good purpose.

Because this bug is caused by PHP it will not be fixed in Drupal. I'm providing this fix to give relief to those that cannot upgrade their version of PHP. The code i'm providing (i.e the code I retrieved from the PHP bug report adapted for Drupal) should work even when PHP is fixed.

The fix worked on my system and i'd like to hear from everyone that is experiencing this problem. The things I want to know are:

* System on which you're experiencing the problem and the version. E.g mine is Debian 3.1, PHP 4.3.10.
* Whether the fix given here fixes your problem.

I've submitted a Debian bug report for the stable package and we'll see what happens from there. I don't have the time to install an up-to-date release of PHP and confirm the problem is still occurring in that release. This must be before submitting a bug report to PHP developers.

The Fix
Add the following code to the end of affected settings.php files then remove all relevant cookies from your browser:

fixCookieVars();

function fixCookieVars() {
  if (isset($_SERVER['HTTP_COOKIE']) &&
      !empty($_SERVER['HTTP_COOKIE'])) {
    $allCookies = explode(';', $_SERVER['HTTP_COOKIE']);
    /*
     * Get rid of less specific cookies if multiple cookies with the same
     NAME
     * are present. Do this by going from left/first cookie to right/last
     cookie.
     */
    /* Reset the $_COOKIE array */
    $_COOKIE = array();
    /* Repopulate it, but now correctly */
    foreach ($allCookies as $cookie) {
      /* Split NAME [=VALUE], value is optional */
      $cookie = explode('=', $cookie);
      $key = preg_replace('|\s|', '', $cookie[0]);
      $value = isset($cookie[1]) ? $cookie[1] : '';
      if (!isset($_COOKIE[$key])) {
        $_COOKIE[$key] = $value;
      }
    }
  }
}

The performance penalty of this fix will be minimal for standard Drupal sites. It increases with each cookie your site sets/accepts.

--
Sammy Spets
Synerger Pty Ltd
http://www.synerger.com

Sammys, I think this is a different bug from yours. Also, you are using a version of php below that required for Drupal.

Anyway, I can confirm this bug on php 4.4.1

And better yet, it doesn't matter which browser. Could this be a problem of using multiple browsers?

On my laptop, I can't log in using FF but I can in IE
On my desktop, the opposite is the case.

I hope my users are not experiencing this problem as well.

+1 on crunchy's patch

Note: Patch prevents cookie gum-up in the future but already gummed up cookies need to be deleted by the user.

Crunchy's patch in #3 does still apply and looks okay to me.

To reproduce: Add ini_set('session.cookie_domain', '.example.com');. If needed to test locally, set yourself up with a mini-TLD using /etc/hosts. The first cookie set will persist and the second will be regenerated.

I think the code comment in #3 should mention why we want to do so.

Instead of handling individual cookie strings, I approached and solved the problem by regenerating the session just after authentication like this.

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 adding the regenerate code (commented with my username iDonny), you clear the anonymous session and open a new one for the logged-in user.
Here are the details on my solution the Drupal login failure without error message issue.

addition/correction to my earlier answer: it is necessary to comment-out the three lines preceeding the function:

user_module_invoke('login', $form_values, $user);
//Silencing the next 3 lines as commented
// $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))) {
    session_regenerate_id(); //Create a new session just before login - also above 3 lines silenced
    $user = $account;
};

This issue is similar/same as http://drupal.org/node/66428

iDonny: where/when does the new session ID get saved (in the sessions table)?

on examining the sequence, I see your point. I guess that I was too focused on preventing the old session cookie from blocking login, and I stopped tweaking just after it seemed to work. I should have moved the sequence lower so that the ID can be regenerated and stored after authentication.

Something like:

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

Do you think this is a better approach?

If that fixes the problem, yes. :)

+1 on latest modifications to patch by iDanny.

After trying multiple patches/fixes/workarounds on 4.7.2 site on PHP 5.0.4, this finally solved the problem in both IE and FF.

Many Thanks. Nothing detracts from a website launch like not being able to log-in.

iDonny, sorry for the typo.

Can we have a patchfile for this?

hi there,
having the same 'double login' problem. using drupal 4.7. didn't have any trouble with the 6.5 version prior to upgrade. i tried the patches offered on this page, with the exception of the patch offered in the #30 post by sammy without any success. i use both firefox and ie, and the problem persists in both browsers.

have tried a few other patches i could find that have been offered for the same problem without success.

...

Session is regenerated and stored in the DB right after authentication to get rid of the 'before login' status that was causing the display of a login box after logon.

Here is the updated patch that is better thought-out that should work uniformly (attached).

How can I apply such a file? (Having probs on 4.7.2 with PHP5)

Ebait, please do not use the issues queue to get help on patching. Consult the relevant handbook pages or ask on the forum.

--Thanks anyways.-- sorry for messing the thread.

But.. it doesnt work for me though. (I have WinVista, so the Win32 patch utils dont work, and I addapted my users.module manual.) Any other ideas?

eBait, the issue tracker is NOT for support requests on how to install patches!

Please read the documentation or ask on the support forums, and stop hijacking this issue!

patch on #46 does not work when browser cache is clean and drupal cache is disabled

(when trying to log in you get to the login screen with no indication of any error, logging in again is succesfull, also logging out gives a header already sent message)

fyi: i have already tried the patch offered in post #46 without success...

Just a quick note: have tried all of the above with no success. If money (small amounts) will help move this along, please contact me.

I initiatied a discussion here (http://drupal.org/node/69262) about a problem very similar to the ones that have led to the discussion every one is having here. Our site was experiencing problems with users regularly being forced to enter their login information twice, and also not being effectively logged off when they thought they had logged out.

In our case, the source of the problem turned out to be an issue with settings.php. Most of our users were entering our site through a login page at (for example) www.example.com . However, the $base_url variable in settings.php was set to be just example.com . This -- and the fact that our "login" page is also our "access denied" page -- led to an internal conflicts between Drupal and the browser management of session IDs which, in the end, created the multiple login scenario. (See the content I reference above for *much* more detail on this.)

I suspect many of the users who have used all the patches mentioned in this discussion, but are still having problems, could be having those problems due to the kind of settings.php issue which we had.

Moreover, I think what happened in our situation raises some questions about how the Drupal code should deal with such situations. I don't think I'm exaggerating when I say that the way Drupal reacted is a real security issue.

Note that the problems we had occurred despite our using the very latest (or just about the very latest) version of user.module.

Hope this helps!

It's still a cvs issue, and people have reported that the latest patch doesn't work.

It not worked to me... :( 4.7.2...

Just to report, I'm seeing the same problem on 4.7.2 - only on my work machine in IE, not at home in FF, but I've no idea if that's significant. Either way this is a very serious bug IMO, and needs the urgent attention of one of the core developers.

crunchy's patch for 4.7 worked for me on 4.7.2. Fixed this problem and I agree that it is a huge one. I haven't looked at iDonny's patch yet. I'm switching this back to 4.7.2 as it is definitely not exclusively a CVS issue.

I think iDonny's patch at #46 (http://drupal.org/node/60584#comment-106861) is malformed. Can anyone confirm or iDonny can you submit a correct patch if this is not just my own user error?

I finally figured out how to reproduce these seemingly randomly occuring bugs. I can only do it on sites that are accessible at both http://www.site.com and http://site.com and have www.site.com set as the $base_url in settings.php

Furthurmore I haven't been able to reproduce it yet on machines outside of my hosting company (surpass hosting)

Instructions:

In IE, log into the site from the www address. Now log out. Go to site.com (without www) and log in. You should be forwarded to www and logged in. Log out, and then try to log back in. It fails (at least on my site)

I've managed to stop the bug in FF with code fixes like the ones posted here, but it still persists in IE.

If you can't reproduce this on your own servers, then try my site http://www.campusbin.com. Prefix any test accounts with drupal_ so that I may delete them later

Done some more testing.

FF is NOT totally fixed. You can still log in, but you must do it twice after you break the cookies using the method I mentioned above for IE. So on FF it will fail only once, but on IE once you break it it fails infinitely, no matter what patches to user.module there are.

Sammys was definitely on the right track also in comment #30, but there must be a better fix than that, going to try iDonny's patch now since I have a way to actually test it (instead of having to wait for people to develop the problem randomly)

Done some more testing. iDonny's patch does not prevent me from reproducing the bug even after deleting cookies.

Also, I have confirmed the domain leveling bug by deleting only the site.com cookie in my browser and not the www.site.com; when I did that, the site worked normally.

So an explanation of what happens in my example above is in order!

When you first log in with site.com (and thereafter: site.com login even works when the bug is blocking your login) it creates a session with a cookie for site.com. Your browser is forwarded to www.site.com because that's the default in settings.php

You get logged into www.site.com because the site.com cookie is sending a sessid that is logged in. meanwhile, drupal picks up this session and uses the site.com cookie, never creating a www.site.com cookie. this means anything you do now is in the site.com session cookie. Now when you log off, that session ID is maintained in that cookie but logged out and now anonymous. When you try to log into www.site.com drupal will create a cookie for it.
This is where the patches are supposed to work, but they don't, because the anonymous session cookie that we are trying to kill is in a different higher level domain and therefore won't be allowed by the browser. session_regenerate_id() might be failing for the same reason.

PHP.net says this of session_regenerate_id():

4.3.3 Since then, if session cookies are enabled, use of session_regenerate_id() will also submit a new session cookie with the new session id.

This might mean that session_regenerate_id() is sending the new session id to the www.site.com cookie, which will have no effect.

I'm not sure how this explains the bug in FF but it definitely does in IE

Most users will not notice this bug, because relative links mean that anyone who accesses the site at site.com will not find a link anywhere on the site to www.site.com EXCEPT for when they use forms, because that redirects using the base url.

if www.site.com is your default url, it will be even harder. This will really break when people just type site.com into their browsers or search engines or an external site links you wrong.

The reason why none of the patches work is because they're modifying the cookie that's perfectly fine instead of the one that's overriding everything. Browsers will not allow such a patch to modify another domain's cookie because that will be a security risk. The only way to alleviate this problem seems to be setting settings.php to site.com instead of www.site.com. This would mean that users will be redirected to the stronger url rather than the weaker when they log in or use a form, meaning that very few will ever notice a problem unless they navigate backwards or follow a link to the lower url.

Given that we can't change another domain's cookies, this seems like it's going to be a pain in the ass to fix, especially given the fact that peoples base urls can be anything and any number of levels below the domain name.

I also think that we might be talking about two different problems. The pre 4.3.3 people might be experiencing the failure of session_regenerate_id(), which crunchy's patch fixes by manually killing the old cookie and forcing a new one to be sent. People like me who are running on higher versions of php might be dealing with the domain issue. Both would appear to have the same symptoms, I think, and they may even work in tandem

Note: campusbin.com is now using a rewrite rule to send people only to http://campusbin.com, therefore it can no longer be used as an example

@robroy, it may not be exclusive to cvs, but the point is that the problem exists in cvs, too. Cvs should be fixed first.
It would be silly to have a fix applied to 4.7 and close the issue, only to find out months later that the problem comes back when upgrading to 4.8.

We have an excellent 4.7 branch maintainer, and I'm sure he'll backport the fix once it has been applied in cvs.

Fool2: I believe PHP versions lower than 4.3.3 is of little concern because, IIRC, Drupal 4.7 requires that at minimum.

Maybe the problem you have been experiencing could have been solved by forcing the site domain to work with or without www using mod_rewrite rules in .htaccess file. That way it would have not been possible to create a cookie behind the wrong domain.

You may also wish to set the cookie domain in settings.php

ini_set('session.cookie_domain', 'www.example.com');

...or

ini_set('session.cookie_domain', '.example.com');

Note that last one is prefixed with a dot.

I believe the bug in PHP with cookies is related to the cookie path. There may be the same session cookie defined for different paths with different values. This is where the fixCookie method coded by Gallery devs come into play. However, the cookie path could also be defined in settings.php.

There might be different problems here. I believe it would be easier if everyone was forcing the domain (with or without the www part) in .htaccess and explicitly setting the cookie parameters in settings.php and all that matching the domain used in the sites subdirectory.

Agreed. It would be a good fix in drupal to set the session cookie domain to the domain of the base url. This can probably be done in bootstrap.inc in conf_init() when it initializes the base path.

I'm not sure if this means that people will still run into conflicts between different domain levels if they have old cookies on their system. This would just prevent dual cookies from being sent in the future.

Another solution would be to rename the session cookie depending on the domain, so that the values cannot collide. This is complicated, however, and may hurt the code overall. It could probably be abstracted in the database as system variables, but it also means that base url is not required and does not have to be set in settings.php
The cookie name would be changed by hitting session_name() in bootstrap.inc
There would have to be some sort of extensible standard for it, though, like SESS01 SESS02 SESS03
System would then save the appropriate session name with the appropriate domain cookie, and be able to recognize it as well

But that's a big change from something that's just static right now.

I'm going to try the first one tonight and get back with the results.

Not so complex, you can do the following in settings.php

ini_set('session.name', 'PHPSESS01'); // default is PHPSESSID

:-)

This is happening to me every day now - Firefox at home is fine, but every morning IE at work has logged me out, and won't log me back in until I've cleared my cookies (or at least it won't show me a logged in page - according to the log I've opened a session for myself each time). I've installed crunchy's patch with no effect.

Does anyone have an answer for this? Are the core devs looking at this issue? How can such a serious bug still be present in 4.7.2?

Tried idonny's patch, and guess what - no change. Every day I fire up IE at work, and find I'm logged out. Every day it's impossible to log back in till I clear my cookies.

Somebody must have some idea what's going on here. It's doesn't seem to be happening to any of my users yet, but it seems like just a matter of time - and the way things are here, it'd be quicker to rebuild the site with another CMS than find a patch that works.

I love Drupal so far, but this is a major downer.

setting the $base_url seens to solved the problem for me....

Settings base_uel works also for me!

I give up.

The only solution I found will not work for everyone. I used a rewrite rule to redirect all urls to www. I killed all of the old sessions by clearing the sessions table and changing the cookie name using the code above.

Changing $base_url does not fix the problem for me. For me, the problem seems to be strangely intermittent and not always reproducible. It seems to happen more with Internet Explorer. Is it worth installing the patch or should I wait for 4.7.3 and hope it will be fixed?

The only way for it to get fixed in 4.7.3 is for people who can reproduce the problem to test the patches. So if that's you, please test!

I had the double-login problem today with FireFox (Mac OSX) on Drupal.org itself.

I've never had the problem on my own drupal site, but I'm using .htaccess to redirect example.com to www.example.com.
Also, is this a duplicate of this issue? http://drupal.org/node/70521

Nothing of the above solved the problem in my case.

It appeared when I update 4.7 to 4.7.2....
I´ve tried ALL.

A quick walk-around that works for some people and that I am yet to investigate is to NOT use the login box/block, instead, use the URL .../user to go to the user page and login from there. This in addition to any patches that regenerate session IDs in the cookie.

When it happens, one of us will take somet ime to investigate the root of this issue (especially it's relationship to the left login block) and find a permanent solution

Tried every single one of these patches and nothing worked.

VERIFIED:

- is NOT a problem of subdomains or www vs no www. Cookie is and was always set as www.domain.org and was never replaced properly. Also, cookie set as stafford.domain.org was always set as such and never replaced properly. Logins, when cookies were cleared, worked correctly for these -- login to www.domain.org did NOT cross over to stafford.domain.org and vice versa, yet each worked correctly in and of itself -- when the corresponding cookie was manually deleted.

- sessions did in fact open, as reported in watchdog, yet user login screen always appeared and attempts to go directly to, say, admin, were rebuffed.

- iDonny's patch, applied as above and also six ways to Sunday, did not have any visible effect in FF or IE.

- Other patch (removing cookie) did not have an effect.

- Patch to settings.php removing all cookies did not have an effect.

However, I realize I am behind the times...

PHP Version 4.3.2

(Flame away, I have my reasons.) I simply patch search.module for my old version and the remaining Drupal features have worked fine for me since I began using it. I have no less than twelve sites running various drupal-4.x implementations (some off the same codebase and some not because of web log reporting needs) and all are fine until 4.6.8.

SOLUTION: I finally replaced user.module with

// $Id: user.module,v 1.454.2.21 2005-11-29 20:14:29 dries Exp $

from an older installation and all sites using 4.6.8 now work perfectly.

Hope that helps someone.

Let's keep the title, shall we?

HI
FIX FOR 4.58 runnin on php 4.32 (I have no choice)
WORKS!
THANKS CRUNCHY I updated your code

if (function_exists('session_regenerate_id')) {
$old_session_id = session_id();

// destroy the cookie on the client to prevent the existence of two domain cookies
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}

//below replaces Crunchy's session_regenerate_id();
if (!$_GET['mode']){
session_start();
session_regenerate_id();
header('location: '.$_SERVER['REQUEST_URI'].'?mode=destroy');
} else {
session_start();
session_destroy();
}

Realised this bug is assigned to me. Changing to unassigned.

Does anyone know if the automated log-out module can solve this problem?

Am not believing this is actually an issue this far along the development path. Thought it was an anomoly for a while, just having to do with my girlfriend's buggy computer. But now clients are reporting it, too. Embarassing to say the least. Wish I could be more help than just complaining...

That's a negative about the Automated logout module apparently.

Does anyone know if this update to the cvs user.module fixes the problem:

Revision 1.612.2.12 - (view) (download) (annotate) - [select for diffs]
Fri Jul 7 10:54:44 2006 UTC (2 weeks, 1 day ago) by killes
Changes since 1.612.2.11: +18 -6 lines
Diff to previous 1.612.2.11 , to branch point 1.612

#70521, patch by Morbus, "Double logins", caching, and logging in and out

It sounds like it, but I know there were other issues too, so am a little confused.

If yes, the next question would be - can someone run the cvs user.module on 4.7.2 and be ok?

Thanks,
Caleb

CVS version didn't work for me. Also with the commenting out regenerate_session_id it doesn't work. Argh. Everything was fine with drupal 4.6.2...must really be a 4.7 issue with the user module.

One of my members said:

I'm on Firefox, and it initially refused to allow me to login. I managed to by-pass it after requesting a password reset.

However, now I cannot post. I receive an error message telling me "You have to specify a valid author."

Best info I can find - run cvs version of user.module and then this hack:

read all through these, no patch worked for me (not sure if I applied it right?). But the guys who were looking into the user.module around this sessions area are on to the right path for a true reason and fix:

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

Anyways, I just commented out //session_regenerate_id(); and then it worked fine!
What does that funtion do? How can it be reviewed / fixed?

Seems to have worked for many people. Am going to give it a whirl.

I investigated my problem further. My issue is not a session problem I believe, I commented out the session code, and tried to login with various accounts. I could login with several accounts, but with others I couldn't. When I had the session code enabled, the session id regenerated correctly. So for me, the problem doesn't lay in the session management. The accounts I can not log in with, are always the same accounts. I also manually reset a password with the md5 function in phpmyadmin for an account I couldn't login with, and I still can not login with that account. The problem for me seems to be somewhere in the user/password authentication, not with session management. Could someone be so kind to point me in the right direction now? Is there a known issue about this aswell? I tried searching but it's mostly the session problem people come up with when I search for login problems.

I FOUND THE PROBLEM!
the accounts that have a name with underscore and no spaces, like for example "test" work. Account names like "test_name" or "test name" don't work! Is this intentional? It worked in previous versions of drupal.

Am wondering if we are talking about the same issues anymore and/or if there are more than one. I've had problems with user names that did not have spaces or underscores, like "demo". A different solution for each user I guess.

Yeah, I don't think it's related to special characters.. I'm just 'webchick' yet I get this error from time to time on both drupal.org and groups.drupal.org.

Note on CVS version of user.module no worky by just dragging into 4.7.2 it will seem like it is, but if someone tries to register or get their password sent to them it produces an error. Replaced CVS version with original version and commented out the regenerate line. So far no reports of problems from any users about not being able to log in, but I need to do more of my own testing on a PC to confirm (never has been a problem on my mac).

+1 for #46 patch

Fixed an issue we were having which could be reproduced as follows:
1: Browse to internal site page
2: Click a logon link to go to /user/login
3: Site logs in as normal and redirects to /user
4: User browses away from /user, is still appears as logged in
5: User browses to the original page (from 1)
6: Cache is not refreshed and the user is shown the cached page as if they were logged out
7: By hitting refresh the page is downloaded and the user now appears to be logged in

This was with Drupal 4.6, and occured with php4.4 and 5.x
Note that this patch did not work until the Drupal cache was cleared

+1 for #46 patch

Fixed an issue we were having which could be reproduced as follows:
1: Browse to internal site page
2: Click a logon link to go to /user/login
3: Site logs in as normal and redirects to /user
4: User browses away from /user, is still appears as logged in
5: User browses to the original page (from 1)
6: Cache is not refreshed and the user is shown the cached page as if they were logged out
7: By hitting refresh the page is downloaded and the user now appears to be logged in

This was with Drupal 4.6.8, and occured with php4.4 and 5.x
Note that this patch did not work until the Drupal cache was cleared

Hi,

1) I want to report the same problem;

2) On IE and Firefox there is a security tab that allow people to set which sites are secured or not. Then you can allow to send cookie, once or every times. I have configure my two versions with the domain name only (ex. If http://www.mytestsite.com then use mytestsite.com). It seems to work with me on IE and Firefox (done it twice). Can anyone try this and provide feddback ?

Hope it could help

Bertrand

Note than in IE prefs, there is 2 section that can be configured :

security -­ trusted site
and Privacy

I have added my domain in both section

New code in 4.7.3:

    // Create a timestamped final URL so that browsers don't return the user to
    // a cached page (where it would appear as if they never logged in or out).
    return array($_REQUEST['destination'], 'time='. time());

Has anyone tested? Does this work?

The code above seems to correct problems with Drupal itself caching login/logout pages. I'm pretty sure it's a totally separate issue. See: http://drupal.org/node/70521

#46 did not actually solve the problem I was having, despite what I said before :)

If you can reproduce this problem, try applying http://drupal.org/node/70521#comment-120913 and see if you can still reproduce. If not, then you might be looking at a caching issue rather than a session issue.

Adding this to the settings.php seems to have cleared the problem for me. I haven't been able to recreate the problem since I added this to the php settings section.

/**
 * PHP settings:
 *
 * To see what PHP settings are possible, including whether they can
 * be set at runtime (ie., when ini_set() occurs), read the PHP
 * documentation at http://www.php.net/manual/en/ini.php#ini.list
 * and take a look at the .htaccess file to see which non-runtime
 * settings are used there. Settings defined here should not be
 * duplicated there so as to avoid conflict issues.
 */
ini_set('arg_separator.output',     '&');
ini_set('magic_quotes_runtime',     0);
ini_set('magic_quotes_sybase',      0);
<strong>+ini_set('session.cookie_domain', '.grymwulf.com');</strong>
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',        '');

You actually want to leave out the "+" in the added line above I assume...(?)

This person said that the set_cookie_domain didn't work for them, fyi. Haven't tested it myself, but then I already managed to get rid of the problem with some of the other info I posted in the thread from that link. Still have the double login issue for IE 6 on Windows however...even with the newest 4.7 bootstrap.inc (a newer version than the one included with 4.7.3).

Just used the "+" to signify which line was added

tested my fix with drupal 4.8.0 cvs (5.0) cvs 9/1/2006 - worked correctly to resolve problem

GRYMWULF's suggestion worked for me and I am using 4.6 with civicspace

GRYMWULF's suggestion worked for me also I am using 4.7.2. Login worked fine in all browsers but IE before the fix. Now it works in IE also.

I am attempting to install Drupal 4.7.2 under Mysql 4.1.2 and having the same problem of not being able to login unless I delete all cookies.

I tried inserting this suggested line in sessions.php:

ini_set('session.cookie_domain', '.mayapur.com');

, but got this error when I open the site:

ago
Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /home/ekaji/drupal.mayapur.com/html/sites/default/settings.php:1) in /home/ekaji/drupal.mayapur.com/html/includes/bootstrap.inc on line 750

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/ekaji/drupal.mayapur.com/html/sites/default/settings.php:1) in /home/ekaji/drupal.mayapur.com/html/includes/bootstrap.inc on line 750

I haven't encountered that error unless my sessions where being stored in a non-standard place. And that wasn't even when I was using Drupal. I'll see if I can track that down.

I followed #101 submitted by grymwulf on August 10, 2006 - 01:24 and it worked perfectly for our alumni site stanislites.org. The double login is gone. Thanks very much grymwulf.

After spending 6 hrs on this and pulling my hair, i tried grymwulf code and it worked... what a relief.... thanks a lot.

But i was upset about the fact that this bug still exists in 4.7.3

Attaching a corrected patch file for #46 from iDonny. This worked for me. Using Drupal 4.7.3, PHP 5.1.5.

Thanks also to #67 (Fool2) and #68 (markus_petrux), I renamed the default PHPSESSID for each of my settings.php files (for three different sites). Don't know if it helped at all, but I like the idea of having different session IDs for each site.

Note to sraisz at #108 - You may have introduced the "white space" problem when you edited the file. See this thread: http://drupal.org/node/67122. Recommended solution in 4.7.x+ is to remove any ending "?>" tags from the file. Looks unbalanced but is officially supported and works.

That is a good point, ensure that if you are using notepad in the File -> Save as... dialog you save your files in ANSI vs Unicode format. I've not had any problems with that issue using this setting.

There are several issues in here, among them:

• The cookie bug, this is the issue crunchywelch had and he volunteered to open an issue with sammys' port of the Gallery fix rolled into a proper patch.
• Some caching which is resolved.
• Straight quote from IRC: and there are other people who have a fundamental misunderstanding of how sessions work, they cannot be helped, ie: I log on with www, but my baseurl is set to example.com and I'm not logged in anymore.

These and some offtopic made this issue a sorry mess. If you want to report a login issue make it into a separate one but make it into a valid report (I have this PHP & Drupal version set up like this, I did this, expeted this and got that). All rights reserved on taking whatever action on whoever dares to comment more on this issue.

That bug isn't fixed in 4.7.5.

1. You log in once, nothing happens, you log in a second time, you're logged in.

2. Sometimes you have to use a different browser than IE because you end up always remaining logged out in it.

There are no bad logs in my Drupal Admin Panel about it.

On my host I checked which version of Apache I am using...

(It happens all the time for me now, on my remote site.)

PHP Version 5.1.2
Apache/2.0.54

I upgraded Drupal to 4.7.5 from 4.7.4 (and ran update.php). Same problem.

The exact same site on my local machine works like a charm.

Here are some more info about my remote server :

Session Support enabled
Registered save handlers files user sqlite
Registered serializer handlers php php_binary

Directive Local Value Versus Master Value
session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 1000 1000
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /tmp /tmp
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0

I've using drupal 4.7.5 until yesterday I upgrade to 4.7.6 and start to have the same problem here related.. but with a little difference.. I couldn't log from any machine I have include the proper machine who contains the drupal.. if I login by ip (it's a dev environment) but if i try to into with http://localhost:....... it's work always...I don't know why .... I have to do one more test and it's try to give a name to the machine.. but I thought it will no work.

thanks

Hi,

I make some tests about that problem with some version of drupal.. 4.7.5, 4.7.6, 4.7.x and the same result... but at last I put an intro into my hosts file where I direct the ip of the dev machine to a false url... and It works!!! I don't know why when I try access by IP it fails the autenthication and when i use an url it works... i think that may be a fail in the construcction of the cookies... but i haven't the needed knowledge to try to fix it. .. i hope this could help you.

thanks

What browser do you use? I had similar problem with konqueror 3.5.x and no session.cookie_domain set to constant. The code after the comment 'We try to set the correct cookie domain...' in settings.php adds a dot before the IP address (.127.0.0.1), which generates dozens of cookies in konqueror. Try commenting out the domain auto-detection code (optionally set a default) and see if it works, does for me.

Well answering Mr700, we are using some explorer, IE6 and IE7, firefox 1.5 and 2.0 and Mozilla.

I have somre new information about that strange problem :

In the dev machine login by IP is imposible becouse this problem.. so we must to add the IP and give it a name in the hosts file in our windows machine.. but in the production site, we have upload it and prepare all without giving a name, i mean, we are login with the public IP of the machine and it works fine... the only difference between production and develop enviroment is the version of IIS (the newest is in production) and the version of the S.O. but I don't think how this may be important......

I wil go on investigating why.. when i have some time ;)

Hi,

I tried iDonny's fix and it worked BUT I forgot that I made the changes and a few weeks later I added ecommerce to the site and guess what... IT EMPTIES THE CART!

It has taken me ages to figure this out so BE WARNED... calling session_regenerate_id() causes the shopping cart to empty, the items are still in ec_cart but under the 'old' session id.

Fixing it now...

For the record, Drupal 4.7.x under PHP5 requires a fix that modifies user.module::user_authenticate look like this:-
REF: http://www.cmsproducer.com/drupal-login-session-cookie-without-error [^]

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

HOWEVER, Donny didn't seem to realise that this causes the current contents of the shopping cart to vanish because the id has changed. In the ec_cart table the 'cookie_id' must be changed to reflect the new session id as follows, adding a new SQL update after the session update...

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))) {
    // iDONNY
    $old_session_id = session_id();
    session_regenerate_id();
    db_query("UPDATE {sessions} SET sid = '%s' WHERE sid = '%s'", session_id(), $old_session_id);
    // (sjc-06-03-07) Maintain contents of the cart
    db_query("UPDATE {ec_cart} SET cookie_id = '%s' WHERE sid = '%s'", session_id(), $old_session_id);
    $user = $account;
  }

That's it. Initial test on the local dev server indicate 100% fix and no side-effects, now for the real site!

CORRECTION!

Second SQL should read:

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

http://drupal.org/node/56357 fixes this.

Correction:

db_query( "UPDATE `" . "{ec_cart}" ."` SET cookie_id = '%s' WHERE cookie_id= '%s' ", session_id(), $old_session_id);

now this code will work on any mysql version. In some cases, the earlier code was not working.

regards
Shishir Gupta