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 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.

@EvanDonovan
Rules for 6.x have changed in one regard that should make this a 5.x only issue; Header add was changed to Header set. See #185075: Only apply "do not cache" headers to files inside the the cache folder. for some of the changes that did get committed. Do you have any thoughts on the Batch API; open a new issue for the Batch API if it's causing problems.

Ok, sounds good. I don't know enough about the Batch API to comment on it at this time. I'll let you know if I find out something reproducible.

Do you still have the same problem or is it fixed now ?

Thanks.

Closing all 5.x issues; will only reevaluate if someone steps up #454652: Looking for a co-maintainer - 5.x

Reason is 6.x has 10x as many users as 5.x; also last 5.x dev was over a year ago. The 5.x issue queue needs to go.

I have the very like symtomp described in #6.

I wrote it here http://drupal.org/node/61900#comment-3385006 with an attached screenshot. Was the first DRUPAL_UID=0 cookie set by boost?

new in 6.x is the "Aggressive setting of the boost cookie" have you tried playing with that setting?
DRUPAL_UID is specific to boost

My user reported this bug just a few days ago. I haven't touch boost settings for a while. But I did modify Drupal settings.php to decrease the cookie expiration time.

boost_init() is called once, why the cookie is set twice in a request? What am I supposed to do? I have Pressflow installed and anonymous sessions are only created on demand. Does not setting the DRUPAL_UID cookie keep boost from working?

if DRUPAL_UID is set then the rewrite rules will skip the cache directory (boost). If you look at the dates the first one is removing the DRUPAL_UID cookie. The second one is the one that sets it. Cookies get removed by setting the date to the past (if I remember correctly).

Thanks for the explain, I didn't remark that. Is it possible to remove the first set-cookie header, as in this specific case it is useless?

I can't reproduce the bug now. But at the time my user reported that bug, 3 users were able to reproduce it (log out, then can't not log in, and remove cookie fixes the problem). I think it is the cookie expiration setting problem now.

Subscribing