Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Depending on configuration settings, proxies, cache, and browsers:
- Anonymous user goes to a page where a login form appears.
- Anonymous user authenticates via the login form (typically, a block).
- Drupal returns the authenticated user to the page they logged in from.
- User still sees the login block, and thinks they didn't log in.
- User then logins again ("double login").
- User force refreshes their browser cache to see authenticated page.
This patch attempts to solve the problem by adding a timestamp on login and logout to the redirected URL. While I am unable to reproduce the bug myself, I have various users that can, and they've eached confirmed that the patch solves the problem.
Comment | File | Size | Author |
---|---|---|---|
#62 | headers-cvs-4.patch.txt | 1.13 KB | Owen Barton |
#59 | headers-cvs-3.patch.txt | 1.3 KB | Owen Barton |
#57 | bootstrap_cache_patch.txt | 2.83 KB | hendler |
#56 | headers-cvs-2.patch.txt | 1.12 KB | Owen Barton |
#54 | headers-cvs-1.patch.txt | 583 bytes | Owen Barton |
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commented+1
I was able to reproduce this reliably, and with this patch it does not happen. The login URL is pretty ugly unfortunately.
Comment #2
pwolanin CreditAttribution: pwolanin commentedToday I saw this bug on Drupal.org itself when logging in with FireFox 1.5
Comment #3
Steve Dondley CreditAttribution: Steve Dondley commentedI 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.
Comment #4
pwolanin CreditAttribution: pwolanin commentedI think this may be a duplicate of this issue: http://drupal.org/node/60584
Comment #5
Morbus IffIt's not a duplicate. Proper session handling would have no effect on a browser's cache.
Comment #6
webchickNice, 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?
Comment #7
Morbus IffI had looked there first and was unimpressed with the opportunities available.
Comment #8
webchickfixing status
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedi 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?
Comment #10
Morbus IffPrimarily, 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.
Comment #11
Morbus IffThis 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().
Comment #12
webchickWhat about $form['destination'] = ..?
Comment #13
Morbus IffWhat about it?
Comment #14
Morbus IffTwo other possibilities:
Comment #15
Morbus Iff'Ere's an alternative attempt, following the second bullet above: forcing drupal_goto() in our user_login_submit.
Comment #16
Morbus IffAlrighty, new patch attached which I like better than my original.
I think this nails it more cleanly than my first.
Comment #17
Heine CreditAttribution: Heine commentedWhen I login, then logout and immediately login again via the user login block while on the frontpage, I'm directed to the url:
With the error: page not found.
Comment #18
Heine CreditAttribution: Heine commentedComment #19
pwolanin CreditAttribution: pwolanin commentedJust 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
Comment #20
Morbus IffYes, that's one common configuration that can cause this problem.
Comment #21
Morbus IffAttached 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.
Comment #22
Morbus IffComment #23
Morbus IffConcatenation spacing fix, per merlinofchaos.
Comment #24
Heine CreditAttribution: Heine commentedPatch works as advertised.
Comment #25
pwolanin CreditAttribution: pwolanin commentedApplied 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?
Comment #26
Morbus IffHrm. That is not intentional. I'm not sure why that's happening.
Comment #27
Morbus IffMmkay. 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.
Comment #28
pwolanin CreditAttribution: pwolanin commentedThis 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
Comment #29
Morbus IffCan you clear your cache and try again, under a HEAD installation? I am unable to duplicate this. Anyone else?
Comment #30
pwolanin CreditAttribution: pwolanin commentedOk- sorry. After clearing the cache the problem seems resolved.
Comment #31
Dries CreditAttribution: Dries commentedCan 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.
Comment #32
merlinofchaos CreditAttribution: merlinofchaos commented'parameter' is likely prefered over 'paramater' =)
Comment #33
Dries CreditAttribution: Dries commentedYes (obviously).
Comment #34
chx CreditAttribution: chx commentedNo, paramater as this whole thing is something that belongs to the paranatural :D
Comment #35
drummComment #36
Morbus IffComments revision per Dries, and RTBC.
Comment #37
Morbus IffComments revision per Dries, and RTBC.
Comment #38
Dries CreditAttribution: Dries commentedPatch 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?
Comment #39
pwolanin CreditAttribution: pwolanin commentedFor testing purposes, is the header issue fixed in the 4.7 CVS?
Comment #40
Morbus IffDries, 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.
Comment #41
moshe weitzman CreditAttribution: moshe weitzman commentedwell said, Morbus. even though it is confusing, i'm sure that we are not working around a deeper problem here.
Comment #42
Thomas Sewell CreditAttribution: Thomas Sewell commentedTested the above patch on a stock 4.7.2 install and it fixed the issue for me.
Comment #43
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI got another report that it works, committed to 4.7.
Comment #44
Dries CreditAttribution: Dries commentedBut we are sending these headers with _each_ page:
The browser should not be caching the page to begin with.
Comment #45
Dries CreditAttribution: Dries commentedCould you try the following line:
or
We might have to set the limiter before the session starts ... More details at http://be.php.net/manual/en/function.session-cache-limiter.php.
Comment #46
pwolanin CreditAttribution: pwolanin commentedApplying 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.
Comment #47
pwolanin CreditAttribution: pwolanin commentedI take it back- the double login problem does still occur, though it seems somewhat less frequent a problem.
Comment #48
Dries CreditAttribution: Dries commentedI 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.
Comment #49
yched CreditAttribution: yched commented(subscribing)
Comment #50
pwolanin CreditAttribution: pwolanin commented@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.
Comment #51
frostschutz CreditAttribution: frostschutz commentedIt'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?
Comment #52
pwolanin CreditAttribution: pwolanin commentedThere was another issue on the browser side. see: http://drupal.org/node/70075
Comment #53
Owen Barton CreditAttribution: Owen Barton commentedThis 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.
Comment #54
Owen Barton CreditAttribution: Owen Barton commentedOK - 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?
Comment #55
hendler CreditAttribution: hendler commentedI'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.
Comment #56
Owen Barton CreditAttribution: Owen Barton commentedHere 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.
Comment #57
hendler CreditAttribution: hendler commentedMy 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.
Comment #58
hendler CreditAttribution: hendler commentedIRT 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.
Comment #59
Owen Barton CreditAttribution: Owen Barton commentedHere 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.
Comment #60
Dries CreditAttribution: Dries commentedGrugnog2: 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. :)
Comment #61
Owen Barton CreditAttribution: Owen Barton commentedI 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.
Comment #62
Owen Barton CreditAttribution: Owen Barton commentedHere is the updated patch
Comment #63
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks! :)
Comment #64
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI've reverted the earlier patch and applied the one that got into HEAD to 4.7.
Comment #65
Harry SlaughterI'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?
Comment #66
(not verified) CreditAttribution: commentedComment #67
calebgilbert CreditAttribution: calebgilbert commentedThis is not a fixed issue. I and several other people still have it. Re-opened.
Comment #68
moshe weitzman CreditAttribution: moshe weitzman commenteda 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
Comment #69
manuj_78 CreditAttribution: manuj_78 commentedHi 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
Comment #70
jrstmartin CreditAttribution: jrstmartin commentedI 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.)
Comment #71
drupalzack CreditAttribution: drupalzack commentedI 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.
Comment #72
manuj_78 CreditAttribution: manuj_78 commentedHi 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
Comment #73
drupalzack CreditAttribution: drupalzack commentedThanks 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.
Comment #74
alexis CreditAttribution: alexis commentedThe 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.
Comment #75
drupalzack CreditAttribution: drupalzack commentedTurn off caching...will work as expected
Comment #76
abqaria CreditAttribution: abqaria commentedis there any solution yet ?
Comment #77
reggie75 CreditAttribution: reggie75 commented///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
Comment #78
capitaine CreditAttribution: capitaine commentedSo 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...?
Comment #79
liquidcms CreditAttribution: liquidcms commenteda 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...
Comment #80
liquidcms CreditAttribution: liquidcms commenteda 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...
Comment #81
liquidcms CreditAttribution: liquidcms commentedyeaaa 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...
Comment #82
liquidcms CreditAttribution: liquidcms commentedok, 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...
Comment #83
merlinofchaos CreditAttribution: merlinofchaos commentedIncorrect 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.
Comment #84
liquidcms CreditAttribution: liquidcms commentedyup, clearly...
thanks.
Comment #85
Chill35 CreditAttribution: Chill35 commentedMy 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.
Comment #86
Chill35 CreditAttribution: Chill35 commentedComment #87
Chill35 CreditAttribution: Chill35 commentedJust to clarify, users have to log in twice in Firefox and often indefinately In Internet Explorer 7, in order to be logged in.
Comment #88
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedI haven't experienced the same thing in Firefox, but, most definitely a problem with Drupal 4.7.5 in IE.
Comment #89
jwilde CreditAttribution: jwilde commentedsee this patch, http://drupal.org/node/108663
Comment #90
cellmaker CreditAttribution: cellmaker commentedI 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.
Comment #91
pwolanin CreditAttribution: pwolanin commentedIf private browsing eliminates/blocks some cookies, then that might be expected?
Comment #92
ibexy CreditAttribution: ibexy commentedI 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)
Comment #93
djuricas CreditAttribution: djuricas commentedI 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.
Comment #94
xdakotax CreditAttribution: xdakotax commentedI'm experiencing this issue in Drupal 6.13 still. Is the attachment above compatible with 6.13?
Comment #95
Jason Dean CreditAttribution: Jason Dean commentedYep me too - still happens in 6.13 with normal page cache on. I don't access my site through any proxy either.
Comment #96
highvoltage CreditAttribution: highvoltage commentedI'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
Comment #97
cosmicdreams CreditAttribution: cosmicdreams commentedThis issue is targetted for 5.7, but #95 reports the problem with 6.13. Retargetting to 6.13.