Logged-in-users get logged-out erratically

Some of our users have complained of a similar 'double login' problem.
I thought it could be a local browser caching issue but pressing Shift+Refresh or Shift+F5 doesn't seem to solve the issue.

One "mee too" for this issue.

To add a bit of information: I got this error (admin user logged out) when accessing a page that was modified in the meantime by an anonymous user (a comment was added). I am able to relogin, but if I browse the same modified page, I get logged out again.

I got logged out on almost every page view after login. I had to disable this module.

I get the same problem also, anyone have a solution for this ?

yes me too ... same thing ... are you guys using drupal in a sub directory ?

form me its not an actual log out its more like not reading the cookie by htaccess file

I had this problem today as well, and my theory is that it's related to conflicting cookie expiration times.

Yesterday, I changed my cookie lifetime in my site's settings.php file. I decreased it to 86400 (24 hours).

The .htaccess required by boost looks for a DRUPAL_UID cookie for your domain. Boost won't set this cookie on every access. It only sets it on login. If you're already logged in (i.e. you have a session ID in your cookies and in the session table), you're definitely logged in so Drupal doesn't run hook_user(op login). However, Boost won't consider you logged in unless the DRUPAL_UID cookie exists. So it will serve cached pages to logged in users.

When this happens, clear the cookies in your browser for your domain. Have a look at the expiration times of your session cookies (they begin with SESS by default). are they rational? check when DRUPAL_UID cookie is added after logging back in. Are the expiration times identical?

I dunno if this is the single cause for the problems everyone here is facing. But for my case, this fixed it (for now).

I have also researched this as I have been playing with the boost module for two days now. The answer is in this portion of the sessions.inc file :

if (!session_save_session() || (empty($_COOKIE[session_name()]) && empty($value))) {
return TRUE;
}

You have two options:

(1) Don't expose any user login blocks on page that can be cached. Why ? -> The first time a user visits your site that pulls up the cached page .. no cookie was registered since php/drupal did not bootstrap and drupal is blissfully unaware of your session. When you go to login you do get a cookie on the return response header, BUT as an anoymous user with UID 0 because of the above code (from sess_write). even though you logged in it was not honored by Drupal since you had no cookie / session id to begin with. Try loging in again and you get in now. So best solution is : Do not display login block on cacheable page if user can land on it as the first page or front page.

(2) Second solution is actually a no solution. It is rogue bruteforce way to tell drupal to still process the sess_write , given that boost is enabled with something like this in place of the code above.

if (!session_save_session() || (empty($_COOKIE[session_name()]) && empty($value))) {
if (!module_exists('boost')) {
return TRUE;
}
else {
sess_regenerate();
}
}

It works, BUT do NOT do this!! I just tried it out and soon realized that drupal essentially allowed me to have an autheticated session by still processing the rest of the sess_write although my current session SHOULD not have that relationship, at least not YET!! (next time around yes). If for some reason the cookie wasn't being passed through to the client pc the intention should be to refuse (not grant!!) an autheticated session to the person, period. Please don't do it.

If anybody can think of a better solution I am all ears, but I really see (1) as the only best choice here.

Given what I discovered I do not think this should be categorized as a boost bug, just a caveat for proper use. In the same way you would not want to present any form (including that of anonymous Comments) with Captcha as Cached page the user can land on.

@bangpound : It does actually serve a DRUPAL_UID cookie on the first login attempt from a cached page, check the cookie information in FF (after the first login fails) and you will see the cookie DRUPAL UID with the value (user#) > 1. But at that time if you check the database you will see for that same session id in the sessions table the uid field shows as zero. BOOST gave you a cookie with a UID since the module processed and forwarded to your browser the UID info, but Drupal did not honor the same session as authenticated by opting out of sess_write due to a non-existing session that initiated the login attempt. BOOST recognizes your UID but Drupal does not, and I dont consider it a bug .. it 's a design consideration for security reason I'd hope.

If at all, maybe what needs to be corrected is for BOOST to run the same check as session.inc does and not provide that misleading UID info on that first login attempt from a non-session cached page so as to keep the intention the same as Drupal's core.

I have the same issue. Is it worth trying the dev version?

plan9, is this for 5.x? Sure give dev a try.

Also be aware that 5.x is not actively being maintained.
#454652: Looking for a co-maintainer - 5.x

Sorry to bump versions if this is a 5.x-specific issue, but after looking through the description of the issue, I've realized that the .htaccess for 6.x is similar enough to 5.x that this could be happening to me also. I think this is the "other side of the coin" for the issue I reference in #509562: Cache-Control rules for Lighttpd (so Boost pages don't get cached in the browser cache) & [#509691] - i.e., sometimes logged-in users see a page that should only be shown to logged-out users, and vice versa. I would love to see if anyone else running 6.x-1.0-beta2 is experiencing something similar.

Also, @drupdrips: are you still looking into this, or should it be reassigned?

For me it seems like this happens most often when doing processes which use the Batch API, such as Calais Bulk Processing.