"Double logins", caching, and logging in and out

+1

I was able to reproduce this reliably, and with this patch it does not happen. The login URL is pretty ugly unfortunately.

Today I saw this bug on Drupal.org itself when logging in with FireFox 1.5

I never reported this so I'll do it here. Since about the time Drupal went to 4.7, I've had this double log in problem on drupal.org. The problem comes and goes. It was a lot worse a few weeks ago. Now it seems to only happen occasionally.

I think this may be a duplicate of this issue: http://drupal.org/node/60584

It's not a duplicate. Proper session handling would have no effect on a browser's cache.

Nice, though that big if is rather nasty. :( I imagine it also won't fire if people are using distributed authentiucation or some kind of custom module to thwart the Drupal login process.

Is it possible to generate and append this seed in user_logout and user_login_submit instead?

I had looked there first and was unimpressed with the opportunities available.

fixing status

i love the fix here. is badly needed. the implementation is a bit ugly though. could you please elaborate on why this seed can't be planted during the form build phase?

Primarily, it appears quite difficult, if near impossible, to return query strings from a FAPI #submit function. Both url() and plain text get encoded, causing the seed to be treated as if it was part of the menu path as opposed to a query string parameter.

This is because the returned string from a #submit function is always passed to drupal_goto. drupal_goto, however, expects a query string under the second parameter. In the absence of that, it passes the whole returned string as $path to url() which is then encoded via drupal_urlencode().

What about $form['destination'] = ..?

What about it?

Two other possibilities:

• Attempt to trick PHP's parse_url() function and set $_REQUEST['destination'] to itself + ?seed. This gets a bit difficult because we'd have to check the existing destination to see if there's already a ? in it, and use &seed instead. I'm not much a fan of this possibility.
• Instead of relying on the default behavior of FAPI's #submit (which is to drupal_goto the $_GET['q'], which is then ignored because $_REQUEST['destination'] exists), we actually do our own drupal_goto()'s, passing the second param seed ourselves. This is quite plausible for logging out because it already uses drupal_goto(). For user_login_submit(), however, I'm a little worried what else we'd break - is there a specific /reason/ user_login_submit() is /depending/ on drupal_goto's $_REQUEST['destination'] feature? And if it's not, isn't it duplicate code to then check for $_REQUEST['destination'] ourselves, just to add a query string to it? ['destination'] is used /so infrequently/ in the code, it's either very important, or nearly irrelevant. I don't know which.

'Ere's an alternative attempt, following the second bullet above: forcing drupal_goto() in our user_login_submit.

Alrighty, new patch attached which I like better than my original.

• FAPI friendly - to return a query string, you return an array suitable for drupal_goto().
• Documentation added (per my original one).

I think this nails it more cleanly than my first.

When I login, then logout and immediately login again via the user login block while on the frontpage, I'm directed to the url:

Just had a (new?) insight into the double login problem today. When I enabled the cache on my site, I immediately started to have the double login problem using Firefox. Disabling the cache made it go away. Can anyone else confirm this? My setup is such that I usually log in through a login block that only showns on one single page, rather than through /user. Even still, it seems I have to pull some pages from the cache before the problem kicks in. I can reproduce this on my site plus an identical backup on a different host's server (both running PHP 4.4).

Also I set a 1 minute cache lifetime, so some of the varability people see in this might depend on their cache lifetime setting?

note: PHP Version 4.4.1, Apache 1.3.34

Yes, that's one common configuration that can cause this problem.

Attached patch fixes bug reported by Heine and renames "seed" to merely "time". I felt that "seed" typically /means/ something in the scheme of things (a seed to a random number generator, for example), when here, it actually means nothing but "cache defeater". "time" is a more generic, adequate, and un"loaded" term to use.

Concatenation spacing fix, per merlinofchaos.

Patch works as advertised.

Applied this patch to Drupal 4.7.2 (suceeds with offsets). Seems to fix the double-login problem, but now when I login at /user, I'm redirected to the front page rather than /user/uid. Is this intentional?

Hrm. That is not intentional. I'm not sure why that's happening.

Mmkay. This is due to the new return in user_login_submit(), which presumes that ['destination'] exists (in the case of a /user login, it doesn't -- ['destination'] only exists on a block login form). One option to fix this is to add the ['destination'] to /user as well. The other option is to add a ternary in user_login_submit, along the line of $_REQUEST['destination'] ? $_REQUEST['destination'] : $_GET['q'];. The attached patch adds the destination to the #action of /user.

This still is causing problems. If I log in via /user, I'm still getting redirected to . If I then manually enter the url: /user, I get the login form, not my account! Oddly, this seems to only happen right after logging in via /user. Otherise manually entering /user sends me to a URL like /user/2?time=1151463706

Can you clear your cache and try again, under a HEAD installation? I am unable to duplicate this. Anyone else?

Ok- sorry. After clearing the cache the problem seems resolved.

Can you use proper capitalization/punctuation for code comments? Some sentences start with lower letters. Also, write 'paramater' and not 'param', etc.

Otherwise, the code looks good. Good work.

I think this is ready to go as soon the documentation is made less slang-ish.

'parameter' is likely prefered over 'paramater' =)

Yes (obviously).

No, paramater as this whole thing is something that belongs to the paranatural :D

Comments revision per Dries, and RTBC.

Comments revision per Dries, and RTBC.

Patch looks good, but I'm still a bit puzzled by this. Do we sent the wrong HTTP headers or something? (We fixed a bug recently with headers not being sent properly.) Normally this shouldn't be an issue, should it? Maybe we are just working around the real problem?

For testing purposes, is the header issue fixed in the 4.7 CVS?

Dries, caching headers are not the problem, IMO, unless we've removed them entirely. Consider the following workflow. An anonymous user visits a page. Because caching has been enabled, the browser receives headers that state it may cache the page for x amount of time. Or whatever. The user then decides, on this page, that he wants to login. He does so, and gets sent back to the original page, which the browser has been told (previously, via the anonymous request) to cache. At no time or chance during this workflow can we tell the browser to NOT cache the forthcoming version of the page. In fact, there have been reports (I think merlin mentioned this in IRC, as I was looking into the issue) that he can confirm his browser is not even /requesting/ the page the second time around -- it's loading it directly from the browser-side cache.

well said, Morbus. even though it is confusing, i'm sure that we are not working around a deeper problem here.

Tested the above patch on a stock 4.7.2 install and it fixed the issue for me.

I got another report that it works, committed to 4.7.

But we are sending these headers with _each_ page:

Could you try the following line:

Applying only the fix-headers patch from http://drupal.org/node/70075 to Drupal 4.7.2 seems to fix the double login problem for me in Firefox 1.5.

I take it back- the double login problem does still occur, though it seems somewhat less frequent a problem.

I can't believe this is the proper fix. If it was, there would be millions of websites with time= in their URL. Not going to commit the current fix to CVS HEAD.

(subscribing)

@Dries - From the discussion above and my experience with seeing it happen, I think this may be specific to Drupal becuase it's a side-effect of the Drupal caching mechanism. Maybe in part an interaction with the Forms API.

It's not the Drupal cache returning the wrong page, but definitely the browser. Disabling the browser cache of firefox in about:config (both disk and memory cache) fixes the problem in every aspect. Downside is that it's awfully slow. Why is Firefox caching the login page, and why is it doing so only once (after all, a second login solves the problem, as does a reload of the page)? Anyone ever debug this?

There was another issue on the browser side. see: http://drupal.org/node/70075

This patch is applied to drupal.org - yet I can still reproduce the issue. I have tested this in Firefox, Mozilla and IE6.

Here is the test:
1: Logout of drupal.org, clear cache & cookies
2: Type in http://drupal.org/ in the URL bar and press return
3: Click on the link 'About Drupal'
4: Scroll to the bottom of the page and click the 'login' link where it says 'login or register to post comments'
5: Login using the form
6: You will be redirected back to the 'About Drupal' page, which will show you as logged in (I think this _is_ fixed by the patch)
7: Click on the Drupal logo top left to return to the homepage
8: This page will now show a login block indicating you are 'logged out'

Note that refreshing the final page or turning off your browser cache will fix this problem, confirming that this is a cacheing issue.

OK - here is a patch that fixes the issue, but I don't fully understand the implications of.
The problem is that, when Drupal caching is turned on we are not (AFAICS) sending no-cache headers as Dries implies. Instead we are sending:

Now, the problem is that the browser has been told to cache the page, hence (as Morbus explains) how is it supposed to know that the user is now logged in and it needs to refetch these pages. What this patch does is prevent the browser caching the page in the first page, so this problem does not occur. This is essentially the same as with Morbus patch, except that patch only (by adding a url param) forces refresh of a single page, which - as I show above - is not enough, whereas this patch forces refresh on all site pages.

I am pretty sure there must be a neater way to do this, but I am not sure what that is right now. Ideally the browser should still be able to cache the pages, but we could still somehow trigger a refresh of all pages when the user logs in.
Dries where would the session_cache_limiter declaration go?
Another idea is that perhaps we could use the 304 headers to instruct the browser to maintain it's cache until the user logs in?

I've been working with GrugNog on this.
In another patch I added session_cache_limiter("must-revalidate"); based on http://drupal.org/node/70521#comment-113814 before the other headers added in the patch after the patch didn't seem to work 100% of the time. And it seemed to help. I also made the page cache-expire not by $date - but in the past.
Finally, I also added header("Cache-Control: private",false); hoping this would help because some browsers will ignore must-revalidate.

Based on what I can understand from
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
There are a number of other headers that may be able be very precise about how , when the browser caches. However, browsers can ignore advice, especially with settings.

Here is an alternative patch.

This one adds 'must-revalidate' headers for cached pages and then uses 403 headers to tell anonymous users to keep their cached copy (if the page has not actually changed). At least, that is what it is trying to do, however we need to check that the 403 logic is still correct.

My fix also commented out ETag, see attached.
Etag may be telling the browser to always cache if the etag is the same. But why would the cache be the same if it was now a logged in page?

The patch is for for review only.

IRT http://drupal.org/node/70521#comment-120738
The patch there looks to be the simplest - but in my tests it didn't work.

I think that once the browser get's the 304, or thinks it doesn't HAVE to revalidate, it doesn't, so even if you start sending better headers later it will ignore them. I needed the additional headers in my last patch, but doing something intellegent with the user I think is worth investigating.

Here is an improved version of the patch #56.

I have added an 'Expires' header which forces the browser to validate the cache as it is told. I also added a couple of short comments.

I have tested this with Firefox, Konqueror and IE6.

Here is how this cache works:
* Instead of telling the browser to unconditionally cache the page (as we did before), we tell it that it should validate the cache on each load.
* This means that if it recieves a 304 header it does not need to download the entire page.
* This patch feeds anonymous users 304 headers (as long as the content hasn't changed, as before)
* If a user becomes logged in we feed them 200 headers, plus the usual nocache headers, so they get the updated page

You can use the Firefox TamperData extension to see exactly what headers are sent and recieved for each request to check this is working as described.

Grugnog2: looks good although I couldn't reproduce the problem. Would you mind updating the patch once more? It would be good if we could document some of the knowledge in this patch so people are less tempted to mess with the headers. This could be the snippet you posted in the comments. So, let's add some additional code comments and then commit it to CVS HEAD.

Glad we managed to come up with a proper solution. Rock on. :)

I realised that the check for !$user->uid was redundant, as the call to page_get_cache() has already excluded authenticated users.

I have added some comments documenting the policy of this function with regards to cache headers for anonymous and authenticated users.

Here is the updated patch

Committed to CVS HEAD. Thanks! :)

I've reverted the earlier patch and applied the one that got into HEAD to 4.7.

I've created a 4.7.3patch based on last HEADpatch and applied to my buddy's install. he's running drupal4.7.3/php5.1.4/mysql5/iis5

The symptom he's seeing is that uid1 simply can't login on a fresh install.

This patch does not fix his problem. i'm assumming IIS related. anyone testing on IIS?

This is not a fixed issue. I and several other people still have it. Re-opened.

a new issue with redirect crept into HEAD. patch is in RTBC already. if you are using HEAD, please mark this as dupe. if not, provide details. setting to closed again. see http://drupal.org/node/79614

Hi there,
I am facing similar problems with my site and I think the patch will be able to help me fix it. Only problem - dont really know how to apply the patch as dont know anything about cvs.
Can someone please help please

Manuj

I was referred to this discussion by Heine in regards to ?time=1156999883. I can't tell if you all are addressing this issue in this discussion but I have applied the latest patches here and ?time=1156999883 is still appended to the end of my URLs after logout. If these patches were designed to fix this, they do not.

I have not found a fix for this strange URL. (Also be advised I'm using clean URLs and Pathauto.)

I upgraded to 4.7.3 (stable, not cvs) and I still see the issue, but now it is a little more subtle.

Here's my environment:
4.7.3
Cache enabled
Clean urls
example.com ReWritten to www.example.com

This problem doesn't occur in FF or Opera. But this is how to simulate this in IE 6.0

Clear cookies, cache, history
Login
Will login successfully
Now click on the logo to go to home page(which goes to www.example.com)
You'll get the login box again, even though you are logged in
On the other hand, instead of the home page, you go to www.example.com/node, this does not occur.

Can anyone with a similar environment as above confirm this?

Thanks.

Hi drupalzack
I was having similar problem on my site but jbrown recommended me to modify .htaccess and redirect example.com to www.example.com and since then I have not had any problem as yet.

I tried your method on my site of cleaning the cache and history etc and logged in and then went to the home page using the banner. No problem, the site still showed me as logged in.

I am using drupal 4.7.3

Manuj

Thanks manuj. Can you send me the relevant part of your .htaccess? I have it redirected too...but may be I'm not doing it correctly.

The problem is still happening in all my 4.7 installations and also here, drupal.org, but I've noticed it only happens when I use some browser (IE or Firefox) on Windows. I've never experienced the problem on Fedora Core Linux.

Turn off caching...will work as expected

is there any solution yet ?

///ini_set('session.cookie_lifetime', 2000000);
ini_set('session.cookie_lifetime', 0);

i set cookie lifetime to 0 (in sites/default/settings.php) so no cookie gets created on disk.

this seems to have solved it for me.

PS: You need to DELETE the OLD COOKIES after you do this, else it never lets you log in.
(in IE: Tools > Internet Options > Delete Cookies)
(in FF: Tools > Privacy > Cookies > Clear Cookies)

PPS: I also added the following line in settings.php,
but i dont think it would make any difference
ini_set('session.cookie_domain', '.domain.com');

where "domain" is your domain name.

Thanks,
Rajesh

So which of the various patches above am I supposed to use?

And how do I implement it - there seem to be no instructions on that, is it assumed all Drupal users will know how to use this patch...?

a client of mine is just starting with Drupal - and told me he couldnt log in to drupal.org a couple days ago. I don't know him too well so thought he must have just mis-typed or something.

then today, i addded a client login to my drupal site and sent him login info - he just emailed me to say he couldnt log in to my site either and was having doubts about using drupal due to flaky logins.

Again, i thought perhaps he was just confused... then i tried and sure enough i can't login either. I had never heard of this issue; but came across this post when trying to track down why i am now locked out of my site that i have been working with for 8 months.

- i am using 4.7.3, apache 2.0.47, php4.4.4, mysql 4.1.???, FF/IE6, WinServer 2003

a couple new things today before this happened:

- i made a couple changes to session path in my php.ini as well as cookies path; and just relized i made a typo in path name.
- fixed the typo
- cleared drupal cache and sessions tables
- cleared FF cookies
- restarted apache a couple times

i get no php errors logged now.

still can't login.

I agree with the post above.. is this fixed?, which of these patches is supposed to work?

oh yes.. the symptoms i think are the same as listed here.. when i login in it doesnt complain about my user/pw it just doesnt seem to log me in.. if i log in with bad user/pw it does say bad user/pwd.

i will keep digging (maybe try last posted patch here.. although don't expect much luck)..

this is easily the the scariest thing i have seen in Drupal so far.

peter...

a little more testing

so not sure if my issue is the issue here.. but sounds so close I figured it made sense to post here.

- unlike some of the posts here - i cant do anything to get back into my site (no refresh, clear cache, clear cookies, differnt browsers, restarting apache,)

i have other sites off this multisite.. and i can also not log in to them either AND i have not touched anthing db related to them in days (and this only started a few hours ago).

I get NO php errors and no apache errors.

so i think 2 very wide open possiblities:

- it has something to do with a setting i have changed in php.ini or httpd.conf (although i think i have restored both to earlier settings??)

- i have added a module that is corrupting something (even though it wouldnt be enabled on the other sites; i think drupal still runs some code from the module???) - not sure if that is the case - if it is; seems like a flaw in the core ideology - it should check if enabled; pull out help for module menu.. and thats it... but likely that IS all that happens??

i was going to restore db.. but seems pointless now since other sites are out as well.

still diggin.. gonna be a long night.

peter...

yeaaa baaabbbyyy

ok. i am back in... the problem was a change i made in my php.ini.. but not sure what yet.

i removed the php.ini file from my php install dir root and problem solved - i can login in again (on all my sites)... so a little digging

i assumed php was now picking up ini file from somewhere else on my server.. and sure enough phpinfo() says it is getting it from f:/windows; problem is there isn't one there.. hmmm.. i wouldn't have thought php could run without a php.ini...

ok.. well a little digging.. sure enough there is NO php.ini on my system now.. so will go through in steps to see what i recently changed.. my guess is my cookies or sessions paths were wrong before and therefore not "allowing" this screwup.. and then when i fixed them (today)... and allowed session/cookies... my site broke.. not good.

peter...

ok, not completely sure why this fixed it, but...

i originally (in my php.ini) had:

session.cookie_path = /

but, earlier today; changed it to something i thought was more organized:

session.cookie_path = f:/Temp/phpCookies/

and this caused me to not be able to login.

I tried every combo of leading/trailing slash and forward/back slash and none of these worked.

Clearly this was my mistake - but not sure this should have killed all my Drupal sites???

I do have a couple other CMS sites running off same server and they were all fine with the "bad" setting.

good-night...

peter...

Incorrect use of session.cookie_path will break PHPs ability to set cookies in the browser.

This setting should rarely be changed from / -- and should definitely not be changed from / in php.ini.

I recommend you look this setting up on php.net to see what it does, becuase what you set it to clearly indicates a misunderstanding as to what this field does.

yup, clearly...

thanks.

My head is spinning, can someone summarize what is going on here ?

I am experiencing serious log in problems with 4.7.5.

I followed Killer's advice and updated my web site. Except I updated my remote site because it's over there that i have problems. Now it's worst.

Just to clarify, users have to log in twice in Firefox and often indefinately In Internet Explorer 7, in order to be logged in.

I haven't experienced the same thing in Firefox, but, most definitely a problem with Drupal 4.7.5 in IE.

see this patch, http://drupal.org/node/108663

I just installed a remote site (Drupal v5.7) and have experienced the double login problem.

I found that using Safari 3.0.4 (Mac 10.4.11) with Private Browsing on caused this issue for me. Turning off Private Browsing eliminated the problem. The double login problem did not occur with Firefox. Not tested on any other browser.

This does not occur on my local install of same version.

c

#91: My intent is not to identify this as a bug but as (possibly) something to look out for if you're experiencing the double login issue. Cheers.

If private browsing eliminates/blocks some cookies, then that might be expected?

I am experiencing this problem too. Am using drupal 5.7. I log in, browse to another page. Come back to the main page and the loging form has appeared and I have to log in again. (Browsing back to the previous pages still has me logged in though)

I was having this problem but after I added second snippet from this node http://drupal.org/node/32109 in .htaccess file everything is working OK, except the site is slower now, I think.

I'm experiencing this issue in Drupal 6.13 still. Is the attachment above compatible with 6.13?

Yep me too - still happens in 6.13 with normal page cache on. I don't access my site through any proxy either.

I'm seeing this or something like it also. When I log out as administrator, the page with admin menu, and member related blocks still appear on any page that I've browsed while logged in.

http://www.journeymm.com/blogs/drupal/drupal-loginlogout-caching-problem