This seems to be cache related.
If I log-out it doesn't seem to logout. And if I logout twice it says access denied.
note: if you login to the logout page... it logs you out :D
It seems that if you visit the homepage in the middle of you session and then log-out, your typical navigation menu stays as well as the log-out links... then once you try to go to a access restricted page, it says access denied.
Also logging out once, (even if it doesn't appear you have) then clearing browser cache and refreshing, load's the page correctly (views as if you've logged out)
Possible work arounds
disabling cache in admin/settings/performance
and putting
cache_clear_all($url, 'cache_page');
in the header of your homepage view (input style php, obviously)
Comment | File | Size | Author |
---|---|---|---|
#266 | 197786-266-d7.patch | 2.85 KB | izmeez |
#265 | 197786-265-d7.patch | 2.71 KB | izmeez |
#259 | 197786-259-d7.patch | 2.81 KB | David Hernández |
#255 | 197786-247-d8.patch | 1.93 KB | David Hernández |
#87 | login_linger_d7.patch | 1.44 KB | Jaza |
Comments
Comment #1
wolfderby CreditAttribution: wolfderby commentedUnder possible work arounds I should have said "or putting code" instead of "and putting code"
Putting just that code in my view header seems to have fixed it for me. I still have cache enabled.
Comment #2
drummDoes the page fix itself after holding the shift key while reloading in Firefox? Are all browsers affected?
Does this happen when Drupal's page cache is off?
Comment #3
criznach CreditAttribution: criznach commentedWhat sort of internet connection are you on? Satellite by chance?
Comment #4
wolfderby CreditAttribution: wolfderby commentedI'm on verizon cable internet.
Comment #5
wolfderby CreditAttribution: wolfderby commentedThe page fixes itself when hitting ctrl+shift+f5 to clear cache and refresh the page.
Firefox 2 and IE7 seem to be affected.
No, it does not seem to happen when Drupal's page cache is off, but does seem to when Drupal's caching mode is set to normal.
Comment #6
paulvantuyl CreditAttribution: paulvantuyl commentedIs there any way to only have
only happen at logout, and not every time the home page is visited? Currently I have set the caching to off - my client uses Firefox - but I need to be able to have caching on, which seems pointless to a degree if the cache is being cleared every time the homepage gets viewed. Please correct me if I have interpereted this incorrectly...
Comment #7
paulvantuyl CreditAttribution: paulvantuyl commentedAlso, I am having this problem with 5.6.
Comment #8
Ugljesa CreditAttribution: Ugljesa commentedI am experiencing the same problem, but sometimes a page reload helps sometimes not. [edit] Another thing i noticed. If i log out and then try to log in as a different users, it does not change, i am still logged as previous user. [/edit]
Comment #9
psynaptic CreditAttribution: psynaptic commentedI've just had one of my clients report this as an issue but I can't seem to reproduce it. I'll report back here when I have more details.
Comment #10
cburschkaI've experienced this numerous times with a number of Drupal sites, including drupal.org. I think all of the times I've seen it, I was browsing on a UMTS connection.
Comment #11
psynaptic CreditAttribution: psynaptic commentedWe still haven't been able to track this down or reproduce it. It's probably browser based, something to do with cache or whatnot. Our clients use IE7 (lamers) so that could have something to do with it. What browsers have you guys been experiencing this with?
Comment #12
cburschkaI've seen this in both Firefox 2 and 3. But as said, this is on a UMTS connection where the provider does all kinds of stuff with the content that is transmitted (caching, gzip, etc.)
Comment #13
end user CreditAttribution: end user commentedI just started having the same problems with Firefox a few days ago when I activated caching although I'm can't say for sure if it started after that or after installing a few other modules in the mean time. The site does work fine with IE7 and Opera 9.26
I've installed the following since activating cache
globalredirect
Calendar
Event 5.1 and upgraded to 5.2
Private Message from (UberCart)
Actually I just did some quick testing and I deactivated caching and rectivated it and it seems to for now solved the logout/login issue. I've been trying with several user names logging in and out and it works fine. I'll update if it starts again.
Comment #14
ttosttos CreditAttribution: ttosttos commentedI'm able to consistently reproduce this issue on a fresh 5.7 install using:
1. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.7
2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
3. MS IE 7.0.5730.13
Go to your site and log in. Open a second tab and go to your site. Log out. Go back to first tab and try to log out. You get access denied and are requested to log in. As described above, a success login at this point has the effect of successfully logging you out.
Comment #15
intent CreditAttribution: intent commentedNothing to add except that I added the php code offered by the OP as directed and that is working on my site. Just adding this comment so as to subscribe to and follow this issue.
(Is there a way to subscribe to an issue without adding a comment?)
Comment #16
parrottvision CreditAttribution: parrottvision commentedsame problem for me. definitely seems a cache issue. if I apply the code in #6 will this affect all pages or only home page? I need caching on. I get it intermitently on firefox and am sure I have replicated on safari and IE6 - although I am tired and cant remember well. helpful huh... I am using 5.7
Comment #17
glass.dimly CreditAttribution: glass.dimly commentedThe only thing I changed on the page was to enable cache and now the system won't allow me to logout. So same problem as above. The client needs to cache the site or the server crashes under heavy traffic. I'm using Drupal 5.4.
Comment #18
paulvantuyl CreditAttribution: paulvantuyl commentedI am still having this issue on the most current version of FF. In fact, it is so bad that I have been having to repair tables in the DB because FF leaves connections open...
Something I have been trying to do is get my client to log out, then close firefox to prevent problems. But they are forgetful, so it doesn't always work.
Comment #19
cdemetriadis CreditAttribution: cdemetriadis commentedI'm having the exact same issues with firefox.
It just seems that ff caches the home page. When I logout I get redirected to the home page which still displays as if I were logged in. I then clear my cache and refresh the page and it displays as if I'm logged out.
Does anyone know if there's a fix for this?
I'm using D5.7
Comment #20
introfini CreditAttribution: introfini commentedHi,
I have some clients with the same problem (IE). Deleting all the cache tables and clearing the cookies and the browser cache doesn't fix the problem. The only thing that works is changing the browser!
introfini
Comment #21
gash-1 CreditAttribution: gash-1 commentedI'm experiencing identical issues with both FF and Safari (running on OS 10.4; not tested on windows). With normal caching enabled, all is fine for a day or so, but eventually I see the exact behavior described here. In fact, when it last occurred, a flush of either browser's cache did not resolve the problem (a trick that had worked previously, oddly); I had to disable drupal caching to get things back to normal. I'm using an Ubercart installation running on Drupal 5.7. PHP version is 5.2.6, MySQL 4.1.11. My home connection is via Charter cable. I'm sure the fix posted will work, but wanted to give some more info for those trying to track down and resolve the root of the problem. Thanks.
Comment #22
geek-merlinconfirming the problem with firefox 2 and 3.
(this really sucks)
>Also logging out once, (even if it doesn't appear you have) then clearing browser cache and refreshing, load's the page correctly (views as if you've logged out)
confirming this too here
Comment #23
criznach CreditAttribution: criznach commented#18 - Firefox does not leave connections open, PHP does. Try the suggestions in this post.
http://drupal.org/node/42626
I suspect you're hitting some server side limitation that can be changed.
Comment #24
bigsend CreditAttribution: bigsend commentedI have this exact problem too.
Is there any resolution yet?
Comment #25
cmillet1 CreditAttribution: cmillet1 commentedI just started having this problem as well. I haven't upgraded Drupal or any modules, and this is actually a very minimal installation. I have recently upgraded to Firefox 3 (Mac), which I would say is the cause of the problem, but it's also happening with Safari.
Anyway, I'm just commenting so I can subscribe. And I also find it annoying that I can't subscribe without commenting.
Comment #26
bigsend CreditAttribution: bigsend commentedThe problem went away when I went to Site-Configuration --> Performance --> set Caching mode to disabled. Although I don't want to disable it, clearly there is a problem there....
-BigSend
http://bigsendworld.com
http://mydrupaladventures.com
Comment #27
awolfey CreditAttribution: awolfey commentedI'm having what I think is the same problem, 5.7, using firefox. When I log in, I get a white screen on the url: http://mysite.com/node?destination=node. If I refresh that page I get these errors:
* warning: Cannot modify header information - headers already sent by (output started at ..../themes/velocity/template.php:1) in ........./includes/session.inc on line 100.
* warning: session_regenerate_id() [function.session-regenerate-id]: Cannot regenerate session id - headers already sent in ....../includes/session.inc on line 103.
When I logout I get the white screen on http://mysite.com/logout. When I refresh I get access denied.
This is a new site and I have never had caching on.
This just started yesterday as I was reworking my custom login blocks, but I can't see anything that I screwed up.
Is this the same problem?
Thanks.
Comment #28
awolfey CreditAttribution: awolfey commentedOK, it was working fine in IE6 so I restarted, cleared the firefox cache and my site cookies and all seems to be working again.
Comment #29
cmillet1 CreditAttribution: cmillet1 commentedI really don't think this is a browser problem, or if it is it's a browser AND Drupal problem. I am seeing the problem in multiple browsers. I also have Drupal's caching disabled and that's not fixing it. I've even gone so far as to manually delete all rows in all the cache tables, to no avail.
Comment #30
cmillet1 CreditAttribution: cmillet1 commentedI really don't think this is a browser problem, or if it is it's a browser AND Drupal problem. I am seeing the problem in multiple browsers. I also have Drupal's caching disabled and that's not fixing it. I've even gone so far as to manually delete all rows in all the cache tables, to no avail.
--sorry about the double-post--
Comment #31
cmillet1 CreditAttribution: cmillet1 commentedOk - looks like borked session data. I fixed my problem by clearing the 'sessions' table in my database. Still not sure what caused the problem in the first place, but that worked.
*CORRECTION* Now I won't stay logged IN.
Comment #32
joncup CreditAttribution: joncup commentedi just started having this issue also when i enabled the page cache, i'm going to try the fixes above, but Im going to follow this issue until a fix comes up. -subscribing-
Comment #33
henns20 CreditAttribution: henns20 commentedtracking - having same issue seems like
to recreate issue -
Also
Update:
Comment #34
memenode CreditAttribution: memenode commentedThis happens to me on 5.8 as well, and I also have normal caching enabled and am using login toboggan, but I'm not sure it has anything to do with the problem. It seems to be a caching bug.
I also wonder if this temporary quick fix clears cache for only homepage or all pages?
Thanks
Comment #35
memenode CreditAttribution: memenode commentedThis is a disaster.
I even disabled the login toboggan module, cleared the sessions table, disabled all caching and made sure cache tables in the database are empty, yet the same problem keeps happening and homepage (and possibly some other pages) seem irreversibly stuck to the same state, even after I cleared browser cache (I tried it in other browsers which I never used for this site before and it's stuck to the same page there as well). I can tell it by that it keeps saying the same number of users online, and I also made one node to display on front page, but it didn't.
There's something seriously wrong here. This is why I hate drupal upgrades. It's so unstable and buggy all around.
EDIT: OK, suddenly it came back... I don't really get it. It's as if cache cleared with a delay... Maybe the /tmp directory needs to be emptied too?
Anyway, now it does look like Login Toboggan is the culprit.
Comment #36
bigsend CreditAttribution: bigsend commentedIs there an active bug report for this?
As in, I know there is this thread, but is there an offical bug ID number for this and progress going on? If only I knew enough PHP to help out...
-Thanks
BigSend
http://bigsendworld.com
http://mydrupaladventures.com
Comment #37
pramudya81 CreditAttribution: pramudya81 commentedIt happens on Drupal 5.7 too but only for FireFox. IE performs well.
Regards
Comment #38
watbe CreditAttribution: watbe commentedstill happens in 5.9... I have this problem as well, I can't seem to logout without changing tabs or restarting FF
definitely not logintoboggan causing the problem, I don't have it installed.
Comment #39
mjourney2 CreditAttribution: mjourney2 commentedSame issue with Drupal 6.3:
With caching turned on, it refuses to log me out and when I do eventually log out (e.g. after manually clearing cookies, which some times works some times it doesn't) then it struggles to log me back in.
Comment #40
Damien Tournoud CreditAttribution: Damien Tournoud commentedUnable to reproduce this. This bug seems transient. Please anyone affected give as much detail as possible about your environment (browser, extensions, proxy used, internet provider, Drupal version, installed modules, etc.), and details about how to reproduce. Lowering priority until someone can reproduce this in controlled conditions.
Comment #41
tknospdr CreditAttribution: tknospdr commentedsubscribing
Comment #42
joncup CreditAttribution: joncup commentedhaving this problem with 5.9
Comment #43
Damien Tournoud CreditAttribution: Damien Tournoud commented@joncup: as I said, this issue is hard to reproduce. Please give as much information as possible about your environment (browser, extensions, proxy used, internet provider, Drupal version, installed modules, etc.), and details about how to reproduce.
Comment #44
mjourney2 CreditAttribution: mjourney2 commentedFor my part, I am running Drupal 6.3 and I have the cache turned on. I also have in my template a no-cache meta tag. I don't think this is a browser problem. Here's what I do:
I try to log out, but it returns me to the same page showing me still logged in. If I go to a page that I have not visited for a while, it will show me as logged out.
I think it's just Drupal returning cached pages when it shouldn't be.
Comment #45
matt@antinomia CreditAttribution: matt@antinomia commentedFWIW, I'm experiencing the same issue in Drupal 5.10. "Normal" page caching turned on, also using the Logintoboggan module. When I disable either page caching OR logintoboggan and then clear the cache, the problem disappears. Seems to be occurring for multiple users on multiple browsers. I've cleared the sessions table which doesn't seem to help. Running PHP 5.2.5. Also, the problem appeared after moving the site from one domain to another, which may be an important detail.
[EDIT] Also reporting that it's occurring on Safari 3 (XP/OS X), Firefox 3 (XP/OS X) but not IE 7. [/EDIT]
Comment #46
paulvantuyl CreditAttribution: paulvantuyl commentedResponse to #23:
Your link points to a php problem in Drupal 4... Are you saying that this solution is applicable to versions 5 and 6?
Comment #47
henns20 CreditAttribution: henns20 commentedI have been up and down this list and have noticed problems with this "log-out / cache" issue before - but now that I am starting to build production (with clients) websites using Drupal this has become a big concern... A couple of questions/Observations to see if it can be taken off the list of possibilites....
I will test these to see if they have anything to do with it. but also looking for feedback.
I should mention that I am using 5.10 and Browsers Camino, Firefox, IE on a Mac OSX
[Edit]
point 2 in my comment i guess can't be the case - per the comment above where problem persists in when using PHP5
Jamie
Comment #48
walker2238 CreditAttribution: walker2238 commentedWell I might as well join in here. Thats right the Drupal village idiot... I for one am 99.9% sure (just like a shared servers up time) that this issue is related to performance caching. And like the rest of you I have no clue. And now that I read my post I realize i'm not very helpful. It's only with performance caching enabled that I have this problem. I've been signing in and out for the past hour or so... thats my two cents.
Comment #49
matt@antinomia CreditAttribution: matt@antinomia commentedI worked-around this bug by hooking info the 'logout' $op of hook_user() with a cache_clear_all() as described above, using the following code. Please don't scorn me Drupal gods for working around a bug instead of fixing it!
[EDIT] The above code does seem to improve the situation but does not workaround the bug all of the time. [/EDIT]
Comment #50
henns20 CreditAttribution: henns20 commentedmatt@antinomia,
So just to clarify...to use your work around....
Do you need to create a hook_menu(). Is there any installation of the module... on the modules page? I am just trying to make sense on how Drupal knows to use the code?
this quote taken from comment#1 - what is meant by view header (header of individual view on front page)? would you put the code there
I second the apology...to the drupal gods
Thanks
Jamie
Comment #51
psynaptic CreditAttribution: psynaptic commentedThat code should go in a module, in this case my_module.module. You need to create a my_module.info file to tell Drupal about the module. Then it will become available on the modules page.
Comment #52
matt@antinomia CreditAttribution: matt@antinomia commented@henns20, psynaptic is correct that you also need an .info file to tell Drupal about the module (http://drupal.org/node/82936) and then you enable the module at admin/build/modules. No need to use hook_menu(), which we'd use if we wanted to map a path (URL) to a callback (function). No need to insert the code into the view header (the "header" text area defined in a page "view") if you're using this work-around.
Comment #53
henns20 CreditAttribution: henns20 commentedhey thanks guys - that helps out a lot to clarify - i am suffering from information overload with everything:) so that helped out a lot.
Comment #54
B.P.B CreditAttribution: B.P.B commentedI am having the same problem with 5.9. I log out, then when I enter a node, it shows I am still logged in. Then when I try to log out again, it tells me "access denied".
The module by matt@antinomia had no effect. The only way to solve the issue is to clear all private data from FF. Even then, the problem happens all over again during the next logon attempt.
This is a critical error that makes Drupal unusable.
Comment #55
B.P.B CreditAttribution: B.P.B commentedMaybe this is related to our hosting? I am using hostgator shared hosting. How about the rest of you?
Comment #56
watbe CreditAttribution: watbe commentedquite sure its not because of hosting provider, as this has not happened to any of my other sites on the same host.
But anyway, my host is iWeb .
Comment #57
pramudya81 CreditAttribution: pramudya81 commentedI guess it is something to do with our internet connection.
Using dial up connection, this issue not arises.
In my office using LAN shared broadband connection, this issue not arises.
Only arises when I use my 3.5G mobile UMTS connection.
Regards
Comment #58
henns20 CreditAttribution: henns20 commentedYa the module did not work so well for me either - it seems like it helped get me out of "loop" faster, but did not fix the problem. Does anyone think that panels is the problem. How many of the people are using panels 2 - I am actually using Panels on the frontpage - i just have this feeling that could be the problem - haven't qualified why - but empirically i think it is a problem. I would agree that with this
but i would add..." on production sites."
Jamie
[edit]
I was doing some testing last night and it seems when disabled panels 2. I was not having this problem. Specifically, I have a strong feeling that the panels 2 beta 3...when i use the panels as the frontpage (site information-->default frontpage as a panels page)...this problem is very noticable
Comment #59
luckyday13 CreditAttribution: luckyday13 commentedI don't have much to add, but I wanted to subscribe. For me, my user logout issue became a major problem once I updated from 5.9 to 5.10 over the weekend. I also upgraded a number of other modules at that time as well, but I would not suspect any of them as likely culprits. I can repeat the logout cache error on any browser and my current work around for my users has been to disable the cache (had been set to normal) after reading many of the posts here.
Comment #60
cwittusen CreditAttribution: cwittusen commentedI have the same problem and it is related to the cache setting because it its not set then I don't have this problem. However, I have only noticed it in FF 2.x and now in FF 3.x. I have tried it with IE and I have not had the same issue, only with FF; however once the cache is turned of then FF has no issues at all.
My environment and my clients laptop/desktops are running Windows XP and Vista; my server that is hosting my clients web sites is on Fedora with Drupal 5.10 but I have seen this from 5.7 and up.
/Chris
Comment #61
mithy CreditAttribution: mithy commentedI have investigated this problem a little bit and here is what I found:
Drupal cache system works only for anonymous users. For an authenticated one pages are being built on individually. If the browser has the page requested in its cache, it adds a If-Modified-Since header to the http request. Firefox adds this header immediately after logout. Thus drupal answers with 304 Not Modified, and the page pretending you are still logged in is displayed. So it looks like firefox is caching those pages with no-cache header (pages for logged-in user) by simply ignoring the header. The problem is mentioned on http://www.sriramkrishnan.com/blog/2007/06/firefox-and-ie-deal-with-no-c...
So you might overcome this issue, by changing the line
header("Cache-Control: store, no-cache, must-revalidate");
to
header("Cache-Control: no-store, no-cache, must-revalidate");
in function drupal_page_header() in ./include/bootstrap.inc
Hoping it helps.
Comment #62
paulvantuyl CreditAttribution: paulvantuyl commented@ mithy
Thank you, it appears with immediate/short term testing that it works. Will continue to test.
Using normal caching, just FYI.
Comment #63
matt@antinomia CreditAttribution: matt@antinomia commentedFixes it for me, too. Here's a patch based on mithy's comments in #61. Someone more knowledgeable than me can determine whether this is the appropriate approach, but based on the referenced blog post, it seems like it to me.
Comment #64
henns20 CreditAttribution: henns20 commentedI'm sorry what file is this patch applied to? Thanks
matt: okay great thx again
Comment #65
matt@antinomia CreditAttribution: matt@antinomia commented@henns20: includes/bootstrap.inc
Comment #66
Perceptum-1 CreditAttribution: Perceptum-1 commentedI had some php code in the content of my front page that lists how many active users the site has.
When the code was
the admin user was always logged in, regardless of the browser, or computer. Once I changed it to
the admin user was not automatically logged in on that page. Im not sure if this is a bug or expected behaviour.
Comment #67
terabitez CreditAttribution: terabitez commentedMight not be an acceptable solution because it hacks a core file, but perfectly solves my problem!
@ mithy : Thanks a lot!!!!
Comment #68
philpro CreditAttribution: philpro commentedI am experiencing this same issue in Drupal 6 - I applied the fix that @mithy shared to a site running drupal 6.6 and it appears to have fixed the issue. I needed to manually clear the cache in chrome (1.0.154.43) for it to work. Worked in FF and Safari.
Comment #69
ShannonK CreditAttribution: ShannonK commentedI am a newbie to Drupal, and I do not understand the workarounds, nor if I should use them (I fear fixing one thing will mess other things up that I won't know how to fix). I have Drupal 6.6, FireFox 3. I am connected to a company network, which has a cable connection to the internet. This is a new site I'm building with most of the defaults in place, as I'm just learning. If I login as any user (for instance "admin"), click to any page, then logout, I get the access denied error message. If I click "Home" it shows me as still logged in. So, I click "logout" again, get the "access denied" page (logout page), then if I try logging in as another user, it logs me in, but as "Admin", even though I entered another user's name and password. I could not reproduce this problem when I switched to IE7. However, I do need to find a solution as I am building this site to be used by multiple users.
Should I use the patch above? If so, can someone walk me through how to use it? (sorry, I'm pretty new to this).
Comment #70
skyredwangThe problem is still there for 6.9
Comment #71
jsheffler CreditAttribution: jsheffler commentedI can confirm that the solution in #61 (and #63) works great.
This issue has bugged me for months, so it is great to finally find a solution. For what it's worth, here are my observations:
Steps to reproduce (at least for me, on a site with no other traffic):
With a bare-bones Drupal site, the above steps leave me on the front page, but with "logout" still available. Refreshing the page clears it up. With more complicated sites, though, a page refresh generally does not help, even after clearing the browser's cache. Unfortunately, I am not sure what ingredients contribute to that more-persistent problem, which is, of course, much more troublesome.
In any case, as stated above, the solution in #61 works, eliminating both the trivial and the "more-persistent" scenarios. Any chance this fix will make it's way into core any time soon?
Comment #72
lelizondo CreditAttribution: lelizondo commentedsubscribe
Comment #73
farald CreditAttribution: farald commentedHave applied the #61 fix, problem solved:)
Comment #74
JonoB CreditAttribution: JonoB commentedSeems to have worked for me too. Thank you.
Comment #75
superdorx CreditAttribution: superdorx commentedComment #76
pramudya81 CreditAttribution: pramudya81 commentedhey....#61 worked for me as well...thanks
Comment #77
Les Limthe comments in #70 notwithstanding, there is a patch to this issue in #63 and it needs review.
Comment #78
pramudya81 CreditAttribution: pramudya81 commentedThe solution at #61 seems worked for a logout. However, I must press refresh (F5) to really reload my site content then...
Before applying #61 solution, my next visit would make me see an updated contents of the site. But now my next visit seems always stays the same. Thus, I need to press F5 for it to reload.
-------------------------------------------------------
Sorry for my above comment. I guess it worked out quite well.
Comment #79
ldbl CreditAttribution: ldbl commentedSubscribe the same problem with drupal 6.9
Comment #80
pramudya81 CreditAttribution: pramudya81 commentedI have following question regarding drupal cache. This issue occurs when drupal cache is active.
Admin modify node's content. Authenticated users could see new updated node. However, unlogged users always see old content. How to get rid of this?
For your info, I also enabled node review.
Anyone feel this problem too?
Thanks
Comment #81
losco CreditAttribution: losco commentedSame here on 6.10: cache->normal.
Comment #82
Ivan Zugec CreditAttribution: Ivan Zugec commentedI was having the same problem on 6.10 and added comment #61 fix which worked.
But because we have a company proxy, the proxy was also caching "some" pages.
Comment #83
hapydoyzer CreditAttribution: hapydoyzer commentedPatch in #63 works for my Drupal installation (v5.16 and v5.10 with security fixes).
I reformatted the #63 patch, so it now can be applied with
patch < bootstrap_cache_control_no_store2.patch
command in drupal root directory.Subscribing.
Comment #84
pramudya81 CreditAttribution: pramudya81 commentedWhat about #80? Anyone having the same issue?
One more thing, that I use backlinks.com ads for my site and it says validation fails due to drupal cache....At the end I disable Drupal cache completely....
Poor Drupal...
Comment #85
iamwhoiam CreditAttribution: iamwhoiam commentedHaving same troubles in 6.11 for my homepage, #61 saved it
Cache (Normal)
Comment #86
Jaza CreditAttribution: Jaza commentedI've been having the same problem on a D6 site of mine. User logs in, and the login form and other anonymous elements are still visible. User logs out, and authenticated-user-only elements are still visible. It's been driving me nuts!
Along with the approach in #61, that adds the
'Cache-Control: no-store'
directive indrupal_page_header()
, I've also found it necessary to add this directive todrupal_page_cache_header()
. The former only stops logout elements lingering for anonymous users, while the latter also stops login elements lingering for authenticated users.Patch attached against latest D6 code.
Comment #87
Jaza CreditAttribution: Jaza commentedAlso find an (untested) patch that does the same for D7 (latest HEAD).
Comment #88
gonzalez_ea CreditAttribution: gonzalez_ea commentedsubscribing
Comment #89
Damien Tournoud CreditAttribution: Damien Tournoud commentedI can reproduce on 6.x, on Firefox 3.0.10. 7.x is not affected.
Drupal 7 uses:
Seeing RFC2616, the "store" directive doesn't even exists (no-store is defined, but not store) [1]. Simply removing this "store" directive solves the issue, so I suggest we start by that.
[1] http://tools.ietf.org/html/rfc2616#section-14.9
Comment #90
izmeez CreditAttribution: izmeez commentedHats off to mithy's solution in comment#61.
I too can confirm that his solution works great on Drupal 6.12
This problem has been in all the versions I have used from 6.1 up.
I would describe it as two observations.
1. When logging out sometimes (intermittently) the browser would still show the user as logged in, but attempts to access new pages would result in an access denied message.
2. After logging out, using the browser back button you can still view pages that were viewed previously as an authenticated user. This was an even more troublesome bug than the first.
The solution by mithy fixes both. I have no idea what the downside or performance costs of this are but I owe you a beer.
Thanks,
Izzy
P.S. An example of the second item described can also be demonstrated on the drupal.org site. After logging in, I view "recent posts" and view "my recent posts". Then log out and I use the browser back button to view "my recent posts" even though I am logged out.
Comment #91
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe correct fix is to remove the "store" part (that doesn't exist). If someone could roll a patch, it would be awesome.
Comment #92
izmeez CreditAttribution: izmeez commentedDamien,
On reading your message I tried removing "store" and "no-store" and that does not work while having "no-store" does work.
Thanks for the suggestion. I hope this helps.
Izzy
Comment #93
izmeez CreditAttribution: izmeez commentedI have more to report, some good some not so good.
The solution by mithy in comment #61 as mentioned before works on a pc with Firefox and works fine on tests I have conducted on a MAC with both Firefox and Safari.
However, on testing with a PC using IE6 it does not. I also tried Damien's suggestion to remove all mention of "store" and that did not work on a pc with Firefox and also did not work on a PC with IE6.
So, the solution by mithy is definitely a plus for everything except IE6. I have not been able to test it on IE7 or IE8.
Izzy
Comment #94
webengr CreditAttribution: webengr commentedBTW whatever solution is picked - remember https is different that http!
Keep in mind that if you are using SSL, https, that some browsers like AOL and Microsoft can be darn picky about the cache-control and not storing cache when using encryption.
We are running into this issue for private download on https sites for the upload.module, see
http://drupal.org/node/163445
And so if you are modifying a module's return array, you may want to also do something
like an if/then against $_SERVER['HTTPS']
and return different cach-control for https connections.
There are many articles you can google talking about the MSIE issue with file downloads under https...
but few have the same solutions.
---
I sincerely think that is important to have different cache-control in the output based upon whether the page is served http or https.
Comment #95
JamesAn CreditAttribution: JamesAn commentedHere's patches made against 6.x-dev and 5.x-dev.
As izmeez reports in #92 and #93, removing the non-standard "store" directive does not work. The patches replace "store" with the "no-store" directive.
Comment #96
Damien Tournoud CreditAttribution: Damien Tournoud commentedWe don't want "no-store". I'm pretty sure simply removing "store" works. @JamesAn, could you do your own testing?
Comment #97
JamesAn CreditAttribution: JamesAn commentedHmm.. I can't seem to reproduce the error. I'm trying with 6.x-dev on Firefox 3.0.10, which was reported on #89. I'm following the instructions on #71 to the letter, but all the authenticated bits don't linger when I log out.
I'd like to run tests to confirm if removing "store" does the trick, but I'm obviously missing something here... >_<"
Comment #98
izmeez CreditAttribution: izmeez commentedJamesAn, I wonder if you tried testing both observations I described in comment #90 ?
It may be wrong of me to combine the two observed problems into this one as described in comment #90, but it has been my observation that observation #1, persistence of the logout button is intermittent whereas observation #2 is consistent. For example, logging in and viewing private items such as my account, edit, then back to home or some other page, then log out. Then use the browser's back button.
The solution in #61 helped me with both problems.
My apologies if combining these two observations together is wrong. I would appreciate being redirected if needed.
Thanks,
Izzy
Comment #99
Damien Tournoud CreditAttribution: Damien Tournoud commented@izmeez: having pages in the browser cache that were generated as an authenticated users even after logout is perfectly normal. That's a standard browser behavior we do not need to change. Your first observation, on the other hand is perfectly valid and that's what this issue is opened for.
Comment #100
JamesAn CreditAttribution: JamesAn commented@izmeez: like Damien said, your 2nd observation in #90 is standard browser behaviour. Browsers will still cache pages that require authentication.
Many secure sites will recommend users to close their browser after logout, especially on public terminals to prevent anyone else from snooping into their accounts by pressing the back button on the still-open browser window. They can't see anything else but the cached pages, but that could be harmful enough.
Doing a long Google search, I've pulled up a number of mentions about Firefox not following cache-control directives, mainly concerning the no-store and no-cache directives. I don't know how relevant that is since I still can't produce the problem.
Comment #101
izmeez CreditAttribution: izmeez commentedI noticed the title of this thread has been changed. Personally, I thought the previous title was more appropriate as I do not think it is a problem specific to Firefox. I think the title was previously something like "authenticated content still visible after logout". Nonetheless, I would like to add further to the discussion.
I am not an expert on these matters but it does seem rather counter intuitive to me to have a website with user login that permits viewing content after logout. I am not sure how "standard browser behaviour" is defined but applying the solution by mithy does eliminate viewing content after logout through use of the browser back button. This seems more intuitive to me.
I have done some further tests on IE6 and have found that in many circumstances the solution DOES seem to work, but it is not entirely consistent. There may be other factors at play and feedback from others may help to clarify things. I will also try to do tests on newer versions of IE 7 and 8, time permitting.
Thanks,
Izzy
Comment #102
TapSkill CreditAttribution: TapSkill commentedWill a fix be included in core in the next version?
Has the bug been fixed, or is there no fix working for all glitches?
If nobody has pointed it out yet, I notice caching problems only when logged out. It says I'm still logged in, and all the content I had access to seems to still work, but if I go to admin or user or any of the system areas which do not allow access by default, it shows the login form on that page, and I'm still logged in.
My solution for the past month or so has been to completely disable caching, and the solutions I read seem to disable caching, too... just in the code rather than in the settings.
Comment #103
izmeez CreditAttribution: izmeez commentedDamien,
With respect, in reference to comment #99 wherein the title of this issue was changed, I was wondering if you would be willing to revert it back to its original title as this is not a Firefox specific issue. It appears to affect all browsers.
Thanks,
Izzy
#99
Damien Tournoud - June 3, 2009 - 17:18
Title: authenticated user navigation items linger after logout » Firefox don't revalidate some cached pages due to wrong HTTP headers
Comment #104
netclickonline CreditAttribution: netclickonline commentedIt seems the patch has resolved the issue. I was experiencing this problem as well. It's working fine now in Firefox.
Thanks,
Sameer
Comment #105
JamesAn CreditAttribution: JamesAn commentedSince I remain unable to reproduce this error, I don't know how to test these patches.
@netclickonline, do you mean the patches in #95?
Here are patches that have neither the store or the no-store directives as recommend in #96. Can someone confirm if these fix the problem in both D5 and D6 as this approach is preferable.
Comment #106
hapydoyzer CreditAttribution: hapydoyzer commented@JamesAn, jamesan_197786-105-D5.patch is not working for my Firefox 3.0.10
Only patch with "no-store" works for me.
Comment #107
JamesAn CreditAttribution: JamesAn commentedThanks for testing it, hapydoyzer.
Can we RTBC patches in #95, since those in #105 don't work?
Comment #108
hapydoyzer CreditAttribution: hapydoyzer commentedAfter reading some RFCs(esplecially rfc2616 sec14) and googling I think that it is not a Firefox bug, but a Drupal bug.
"Cache-Control: no-cache" is not indicate that page cannot be saved in cache and used in future. It is only indicate that cache MUST be revalidated first and if local copy is valid then browser can use it. This is similiar to "must-revalidate", except that it revalidate local cache only if page Expired and "no-cache" revalidate it every time.
When you request some page (e.g. / page) as logged in user, page is saved in the cache.
Next time you request same page - it is always revalidated by using If-Modified-Since header. Or client can for some reason simply request this page again without this header.
When Drupal construct responses to logged in users, it always set Last-Modified to current time. Because of this, clients always recieve not-cached pages.
For anonymous users, Drupal use "true" Last-Modified header (true modification time of the page) and return "Not Modified" response if If-Modified-Since value greater than true modification time of the page.
Think of this:
Your browser think of using cached page, but first it need to revalidate it. It requests / page with If-Modified-Since header set to current time minus some seconds (when you been logged in)
Drupal compare true modification time of the page and "fake" If-Modified-Since header (Time of requesting / page when you are been logged in). Druapl see that "not modifications from this time occur" and return "Not modified"
I`m introducing another pair of patches.
This patches add "ETag" header to non anonymous requests.
ETags from anonymous users and logged in users are different even if If-Modified-Since are exact. This implemented by adding special string to ETag when page requested by a logged in user.
This behaviour is stricly divide anonymous and not anonymous page responses.
I`m additionally add "Cache-Control: private" to logged in user page responses to force shared caches not store this private pages.
Currently tested only with FF3.0
Comment #109
hapydoyzer CreditAttribution: hapydoyzer commented>I'm able to consistently reproduce this issue on a fresh 5.7 install using:
>1. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.7
>2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
>3. MS IE 7.0.5730.13
>Go to your site and log in. Open a second tab and go to your site. Log out. Go back to first tab and try to log out. You get access denied and >are requested to log in. As described above, a success login at this point has the effect of successfully logging you out.
It is another issue not related with caching. You can simply go to /logout page if you are not logged in and you see "access denied" page.
Fire a new bug if this behaviour bother you.
Comment #110
hapydoyzer CreditAttribution: hapydoyzer commented>Hi,
>I have some clients with the same problem (IE). Deleting all the cache tables and clearing the cookies and the browser cache doesn't fix the >problem. The only thing that works is changing the browser!
>introfini
This is a very strange and may be related to some parent caches/proxies between your clients and Drupal. I this still (with the latest Drupal core) that?
Comment #111
hapydoyzer CreditAttribution: hapydoyzer commented> Doing a long Google search, I've pulled up a number of mentions about Firefox not following cache-control directives, mainly concerning the no-store and no-cache directives. I don't know how relevant that is since I still can't produce the problem.
Any proof links? In this exact issue I see that Firefox are not violate "Cache-Control: no-cache" or no-store behaviours. (See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1)
"store" is not a valid value at all.
Comment #112
hapydoyzer CreditAttribution: hapydoyzer commented>I am not an expert on these matters but it does seem rather counter intuitive to me to have a website with user login that permits viewing >content after logout. I am not sure how "standard browser behaviour" is defined but applying the solution by mithy does eliminate viewing >content after logout through use of the browser back button. This seems more intuitive to me.
I think "private" data need to be viewed using https, not http. In this situation most browsers AFAIK not store content of such pages even in history.
Even if you use no-store, some browsers can still cache information. Look here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2
> no-store
> ....
> Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation.
Comment #113
hapydoyzer CreditAttribution: hapydoyzer commentedThis is not Firefox bug. Another browsers (if they store pages with Cache-Control: no-cache directive in response) are also affected.
Issue is about incorrect revalidation of pages in Drupal.
Druapl assumes that client cache contain pages from anonymous user view when client are not logged in.
Firefox revalidates pages in this situation, but Drupal return incorrect data.
Just use FireBug and you see revalidation requests from FF.
Correct my English if something wrong, please :)
Comment #114
PatW CreditAttribution: PatW commentedsubscribing
Comment #115
fletch11 CreditAttribution: fletch11 commentedsubscribe
Comment #116
hapydoyzer CreditAttribution: hapydoyzer commentedPatch in #108 tested on Drupal 5 with:
Mozilla Firefox 3.0.10 (Ubuntu)
Opera 9.27 (Ubuntu)
Midori 0.1.2 (Ubuntu)
IE 6 (WinXP)
Comment #117
m.a.king CreditAttribution: m.a.king commentedI Just started testing the patch in #108 for D6 and everything seems good so far (only checked in FF 3.5 and IE8).
Thanks!
Comment #118
mikeytown2 CreditAttribution: mikeytown2 commentedsubscribe
#243115: Hosting Issue - Missing mod_headers: logged out user sees auth pages stored in browser cache if previously authenticated
Comment #119
mikeytown2 CreditAttribution: mikeytown2 commentedIs this bug in 7.x?
http://api.drupal.org/api/function/drupal_page_header/7
http://api.drupal.org/api/function/drupal_page_header/6
If not the patch should be a back-port of the 7.x code
Comment #120
izmeez CreditAttribution: izmeez commentedLooking at the discussion and in particular comment #3, http://drupal.org/node/243115#comment-869439 it is suggested that adding the "no-store" directive to the main .htaccess file is an alternative to hacking the core bootstrap.inc file.
How would it be best to add that directive to the .htaccess file and will that work for a multi-site installation ?
Thanks,
Izzy
Comment #121
Damien Tournoud CreditAttribution: Damien Tournoud commentedI would like to won't fix this one. The explanation in #108 is nearly true, except from one critical point: Drupal does a strict match of the ETag and the If-Modified-Since headers:
If the browser has not sent a matching E-Tag or has not sent a matching If-Modified-Since header, Drupal never returns a 304 answer.
You will have to find the culprit elsewhere. Most probably in a proxy or reverse proxy on your way between your browser and the client.
Comment #122
AndraeRay CreditAttribution: AndraeRay commentedLet me know if my logic is correct. When you click log out it redirects you to the logout page. So can we add this code to the logout page?
Would that then clear all caches when a user logs out, and prevent this error from happening where you can still see authorized content as a logged out user?
--------
61 fixed it for me thanks. Just wanted to throw out an idea.
Comment #123
Damien Tournoud CreditAttribution: Damien Tournoud commentedWon't fix based on #121. The E-Tag is there, it is different between anonymous users and authenticated users. There is no core bug here.
Comment #124
m.a.king CreditAttribution: m.a.king commentedI agree that by looking at the code, this everything should be correct.
However, after updating core, and in doing so removing the patch from #108 (that I had completely forgotten about), I experienced this same behaviour again. After logging out of my account, I was presented a cached page with menus as if I were still logged in (which I was not, confirmed by trying to click on, say, 'administer'). I'd love to understand the reason behind this...
I captured an example of some odd headers using livehttpheaders. Unless I'm missing something here, these 'shouldn't be' (note -- I've anonymized them a bit):
In this case, the request headers do not contain the If-None-Match header (the Etag), so (if my understanding is correct) the condition in drupal_page_cache_header should fail, and thus the response should not be sending a 304....
and yet it is.
Or, at least, it was. As with all 'exciting' issues, I am having trouble now replicating the problem, which only makes me more confused.
Any thoughts on the subject would be much appreciated.
thanks.
Comment #125
NedFlanders CreditAttribution: NedFlanders commented#61 fixed the problem for me.
Has anybody been able to implement this work-around as a module as opposed to hacking core? I tried by doing this:
But that didn't seem to work....
Comment #126
mikeytown2 CreditAttribution: mikeytown2 commentedI think a module could be made to do this, it would use an output buffer and use my latest trick to output the page contents and close the connection while php is still running. See this patch for boost for some ideas... #585424: Faster page loads when adding page to cache; do async opp.
Comment #127
m.a.king CreditAttribution: m.a.king commentedWell, that's it, I'm starting to lose my mind over this one.
Today a user told me that when they visit the front page, they see the login block even though they are logged in (and able to visit, say /admin).
After some trying, I'm able to replicate the issue some times. It appears that the browser is caching the anonymous front page and displaying it for authenticated users. The browser doesn't seem to be sending requests for the front page at all (when the issue is occurring, that is).
That, of course, doesn't make any sense to me.
I tried both solutions above: #61 and #108 (which I need to keep active to avoid seeing cached *logged-in* pages for authenticated users).
I can replicate it pretty easily now (in FF3.5.3):
1- logout
2- force a reload (ctrl-f5, etc)
3- visit the front page normally (should get the 304 response and a cached page)
4- login
5- frustration at seeing the cached page again, even though I am now logged in.
looking at the headers, I see the:
POST /node?destination=node HTTP/1.1
with response:
HTTP/1.x 302 Moved Temporarily
Cache-Control: store, no-cache, must-revalidate, private, post-check=0, pre-check=0
Last-Modified: Fri, 25 Sep 2009 16:44:53 GMT
Location: http://www.example.com/node
then
GET /node HTTP/1.1
with response:
HTTP/1.x 301 Moved Permanently
Cache-Control: store, no-cache, must-revalidate, private, post-check=0, pre-check=0
Last-Modified: Fri, 25 Sep 2009 16:44:55 GMT
Location: http://www.example.com/
then... nothing, which (I assume) means that the browser is not re-validating the cached / (front) page and is simply serving it up blindly.
So far I haven't been able to replicate the issue in IE8, but I haven't tried too hard.
not sure where how to proceed with this now.
edit: this might belong in a new thread.
Comment #128
mikeytown2 CreditAttribution: mikeytown2 commentedJust to let you know, I was able to trace this issue down to apache missing mod_headers when boost is used. This could be related to this issue. Also un-setting Etags in apache seemed to work once, but then that trick stopped working later on.
Comment #129
nelslynn CreditAttribution: nelslynn commentedExperiencing this issue with Drupal 6.14. Will try the mod_headers solution.
Comment #130
danreb CreditAttribution: danreb commentedMe too with Drupal 6.14
Subscribe...
Comment #131
lelizondo CreditAttribution: lelizondo commentedTried with mod_headers and didn't work for me, I'm "still logged in" even when I hit logout.
Edit: With normal cache enabled I have no problem, the problem is just when enabling boost
Comment #132
mikeytown2 CreditAttribution: mikeytown2 commentedThink I might have figured out a way to do this without hacking core. Set these 2 meta tags
Any testing would be appreciated.
Comment #133
John Pitcairn CreditAttribution: John Pitcairn commentedHmm. Subscribing.
Comment #134
Damien Tournoud CreditAttribution: Damien Tournoud commentedPlease also see #550488: Turn off mod_expires for all .php files, which might help in some server configurations.
Comment #135
mikeytown2 CreditAttribution: mikeytown2 commentedHeads up I am able to reproduce this bug finally after adding these lines to the bottom of my htaccess file
People would be adding these in due to yslow's recommendation to remove etags most likely.
Comment #136
Damien Tournoud CreditAttribution: Damien Tournoud commentedAlso, if you are using Boost, please report what you are experiencing in the Boost module queue directly. Boost completely modifies the page serving mechanisms of Drupal, and it is unlikely that the bug you are seeing is caused by Drupal.
Comment #137
Gerben Zaagsma CreditAttribution: Gerben Zaagsma commentedsubscribing
Comment #138
HS CreditAttribution: HS commentedI Have this issue with Drupal 6.14 and three previous versions of Drupal as well. The first post reporting the problem was posted in December 2007. 137 comments, two threads (maybe more), and two years later, issue is still not resolved. Now the status is "won't fix"??
I don't use boost module either..
Comment #139
mikeytown2 CreditAttribution: mikeytown2 commented@HS
Try this patch
#550488: Turn off mod_expires for all .php files
Comment #140
portulacasubscribing
Comment #141
HS CreditAttribution: HS commentedI don't know how to patch :(
Comment #142
mikeytown2 CreditAttribution: mikeytown2 commentedhttp://drupal.org/patch/apply
Comment #143
rc2020 CreditAttribution: rc2020 commentedsubscribing
Comment #144
hapydoyzer CreditAttribution: hapydoyzer commentedI tried to do some tests and found interesting things.
I added debug functions to index.php and includes/bootstrap.inc that dumps varios things to [file] log.
Once the user log out, Drupal correctly handles this and construct a correct page. BUT server return another (old) data.
I don`t use any kind of proxy server. And it seems to me an issue with server rather than with Drupal or client.
My hosting server use nginx on top of apache and I think issue related to cache in nginx.
Solutions with no-store and my solution with etag fixes this issue.
Below headers sent by Drupal:
(Sent from server on Fri, 29 Jan 10 13:11:21)
And what server returns:
Request headers:
Notice different "X-debug-select" headers.
This headers is sets to current time within includes/bootstrap.inc.
Above shows that response is cached by someone between client and Drupal.
Comment #145
hapydoyzer CreditAttribution: hapydoyzer commentedI`ve setup some testcases: http://test.kv-plata.ru
Hosting is uses nginx-0.7.62.
Config for nginx may be available soon if support will give it to me.
Comment #146
drubbIMHO this issue definitely has to be fixed. I've got these problems with various drupal 6.X, versions, and my customers, too. At first only Google Chrome showed this behaviour, but with the latest versions of Firefox (3.5 / 3.6) it can be seen there, too.
I think this is a CRITICAL bug, which makes drupal unusable in serious, security-sensitive production environments.
Turning off caching is NO solution!!!
So what should we do? Hack core modules? Change htaccess settings? Reconfigure servers?
Regards,
Boris
Comment #147
mikeytown2 CreditAttribution: mikeytown2 commented@BorisB
Renable your etags; odds are you disabled them in your htaccess file.
Comment #148
portulacaI had a different front page for anonymous and other roles, the problem was caching and it went away when I installed and configured authcache module to exclude front page from caching.
Comment #149
Damien Tournoud CreditAttribution: Damien Tournoud commentedI'm able to consistently reproduce the issue with a simple stock Drupal 6 in front of a Varnish cache. The issue is indeed that we use the invalid 'store' tag. Changing that to 'no-store' completely fixes the issue.
Comment #150
rc2020 CreditAttribution: rc2020 commentedI'm sure all of us have tried patches and hacks and whathave you, but there's no clear guide on what works the first time, everytime with no exceptions.
However, so far, this module, http://drupal.org/project/loginlogout, seems to solve the problem.
It logs the user out, redirects them to another page and does an access check on the user before rendering the content. I'm not sure if this is the end all be all solution but it seems to log my users out just fine.
Thanks.
Comment #151
HS CreditAttribution: HS commentedThanks for changing the status from wont' fix to active. But what's the fix? How does one change it to 'no-store' and what does it all mean?
Thanks!
Comment #152
Alun CreditAttribution: Alun commentedI'm so glad I found this page. Subscribing. Going to check out the login/logout module.
@HS, the post is referring to http://drupal.org/node/197786#comment-1055633
Comment #153
izmeez CreditAttribution: izmeez commented@Damien #149
Thanks. Does this support Mithy's solution in #61 as the right way to fix?
Izzy
Comment #154
Ela CreditAttribution: Ela commentedsubscribing
Comment #155
webservant316 CreditAttribution: webservant316 commentedsubscribing
Just ran into this bug today. Trying to read through this long post to determine what is the solution recommended by the Drupal development team.
Comment #156
webservant316 CreditAttribution: webservant316 commentedI used the patch at comment #86. Worked for me. I am a little surprised to patching core on such a basic issue. Also after reading this post twice I couldn't figure out if a definitive answer to the delima was explained. The patch worked, but is that all it is 'a patch'? Hopefully the solution is incorporated in 7.0.
Comment #157
hassansr CreditAttribution: hassansr commentedthe fix that worked for me was to modify .htaccess as in this thread
http://drupal.org/node/77106
Comment #158
hassansr CreditAttribution: hassansr commentedthe fix that worked for me was to modify .htaccess as in this thread
http://drupal.org/node/77106
Comment #159
usera CreditAttribution: usera commentedexperiencing this on 6.16 where i get http 304s and i even have performance cache disabled. i personally had post settings -> rebuild permissions to correct this issue... subscribing.
Comment #160
dpatte CreditAttribution: dpatte commentedsubscribe
Comment #161
maomaohuhu CreditAttribution: maomaohuhu commentedI am on 6.16 and I experience the same problem.
I've really enjoyed reading all the posts, but let me add my humble contribution to this cloud of confusion.
First, let me clarify what's going on:
Very easy to reproduce. Happens in FF, Chrome... ( not IE but haven't tested more ).
When the browser cache is cleared, everything is back to normal.
Also when Drupal page cache is disabled, it's back to normal as well.
OK, let me say that the fix suggested by mithy in #61 does the job marvelously.
BUT!! , more than 1 year after this fix was suggested, it is still not committed ?
Is this not the way to go about it ? If not, what is a better approach ?
I don't get it .
I understand this might be a server-issue / htaccess ...
As a matter of fact, this problem arises on a shared hosting plan ( OVH ),
and does not happen on my local machine.
I've read the related post http://drupal.org/node/550488 but it's marked as closed,
thus I assume it's not related to my current problem.
Soooo... in an effort to help understand this better, here are the headers :
1°) LOGGED IN :
2°) LOGGED OUT ( same page , after being logged out )
Hmmm.... are we supposed to hack core until D7 comes along ?
Comment #162
bluedrup CreditAttribution: bluedrup commentedThanks for this patch #61 ... you save my day
For my it work D 6.14
the issues appear only in firefox ... everything is fine in IE
thanks again
Comment #163
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe issue with Varnish is that in its default configuration, it ignores the
no-cache
directive. Issues described in #144 are related to the nginx configuration. Other issues reported here seems related to Boost.Nothing to fix here.
Comment #164
mikeytown2 CreditAttribution: mikeytown2 commentedMy question is where is the store directive in the RFC's? http://tools.ietf.org/html/rfc2616#section-14.9 I see no-store but not store http://tools.ietf.org/html/rfc2616#section-14.9.2 If this is the case then we are not following specs.
http://api.drupal.org/api/function/drupal_page_header/6
Comment #165
david.a.king CreditAttribution: david.a.king commentedas with #80 i have the problem that anonymous users do not see changes until the cache is cleared (time set in performance) while authenticated users do.. what's the reason for this, and is there any way around it?
Comment #166
fax8 CreditAttribution: fax8 commented@Damien Tournoud me, and all the people above are getting this issue on plain Apache + PHP setups. Without any reverse proxy and stuff like that. Personally I'm getting it on my simple site5 shared hosting and there's no (reverse)proxy on the pipe to website. So there's something else happening here, hence reopening.
For my website, patch in #108, which I had to apply manually as it hunked, fixed the issue.
Instead with #63 I still got some problems.
Comment #167
Damien Tournoud CreditAttribution: Damien Tournoud commented@mikeytown2: please open a separate issue for the 'store' directive, which is completely useless (and is not actually valid).
@fax8: what makes you think that site5 shared hosting is a "plain Apache + PHP setup"? It's probably far from it. Having access to a publicly accessible site that has this issue could help debug it.
Other then the irrelevant 'store' directive, we are absolutely not doing anything wrong here, so this is a won't fix again. If removing the 'store' directive fix the issue for you, great, let's just do that. If not, just ask your hosting provider to fix its configuration.
Comment #168
fax8 CreditAttribution: fax8 commented@Damien I'm contacting you offsite to give you access to our server
Comment #169
shyam541 CreditAttribution: shyam541 commentedsubcribing....
Comment #170
sleepingmonksubscribing
Comment #171
phil_esq. CreditAttribution: phil_esq. commentedSubscribe.
Comment #172
gn0rt0n CreditAttribution: gn0rt0n commentedSubscribe
Comment #173
jjwhitney CreditAttribution: jjwhitney commentedsubscribing
Comment #174
roald CreditAttribution: roald commentedSame problem - subscribing
Comment #175
roald CreditAttribution: roald commentedOK - have been testing quite a lot. I'm not good at apache and server-stuff, but anyway - here are some videos showing how I've been able to consistently reproduce the problem in Firefox and Chrome on a shared LunarPages hosting.
I've installed exactly the same system on a local XAMPP, but the problem does not exist there.
The videos are based on this observation: The issue will happen after a logoff on all pages the user visited in his logged-in session that also exist in the page-cache for anonymous users. If either the page-cache is cleared or the local browser cache is cleared, the problem is solved.
So:
Video 1) shows how I am able to reproduce again and again in Firefox and Chrome with Lunarpages hosting, that it is not reproduceable at all with IE and Safari, and not reproduceable at all on my local XAMPP server:
http://www.youtube.com/watch?v=ZyiTlHj8iSA
Video 2) shows that the issue is directly related to cache_page
http://www.youtube.com/watch?v=2KtdgmZnvPg
Video 3) shows the one solution so far in this thread that has worked for me; namely the no-cache fix in #61
http://www.youtube.com/watch?v=tfDSLIFZztY
Update: After making these videos I've been able to create a small helper module that will clear out the cache_page when a user logs off. This should be fine on my site since there are rare updates and 99.9% anonymous users. This also fixes the problem for me. The core of that module goes like this:
If my test-site can help someone more knowledgeable than me finding the root-cause in this issue, please feel free to use the site at http://cache-issue.etvindumotverden.net/
User: user
pwd: user
I've also added a link to clear the cache for those who wanna test :)
Please contact me if you want me to tweak some settings behind the scenes.
Comment #176
mikeytown2 CreditAttribution: mikeytown2 commentedVideo helps a lot; this needs another look
Comment #177
fax8 CreditAttribution: fax8 commentedGreat work on the videos.
I can give access to developers to my server on Site5 which shows this issue and let you debug it from there if you are not able to reproduce the issue. (I can't fix this by myself as I'm dumped with too many other projects right now)
Comment #178
bnavasky CreditAttribution: bnavasky commentedI'm experiencing the issue described above (authenticated permissions persist for unauthenticated users after logout, when using Firefox/Chrome but not in Internet Explorer) on a test drupal installation.
I won't be able to delay the site launch until this is resolved, but it's an unacceptable security risk. Can anyone tell me if there is a downside to implementing the fix described in #61?
Thanks for your advice.
Comment #179
Cyberwolf CreditAttribution: Cyberwolf commentedOn a regular Drupal site with page caching set to normal, when testing with Firefox 3.6.10 and Chrome, we encountered similar issues. a 304 Not Modified got returned after logging out and fetching the homepage, getting a version of the homepage previously cached by the browser when being logged in.
The fix from #61 worked in Firefox, I removed the "store" directive from the Cache-Control header in drupal_page_header() and the front page fetched as logged in user does not get cached any longer. Still trying to fix some Chrome issues.
Comment #180
Cyberwolf CreditAttribution: Cyberwolf commentedReplacing store with no-store seems to solve the issue as well for Chrome.
So the patch from #63 / #95 (identical?) solved the issue here. Solution from #96 and #105 works for Firefox (3.6.10) but not on Chrome (tested here on 6.0.472.62).
Comment #181
bnavasky CreditAttribution: bnavasky commentedPatch from #63 worked for me. Haven't observed any negative consequences.
Comment #182
dpatte CreditAttribution: dpatte commentedditto #181, #63 has worked for me for the last few months
Comment #183
mdupontEditing the title from 'Drupal return "Not modified" response to anonymous even if his browser cache contain page from authenticated user.' in the hope to attract more attention on this issue.
Has someone encountered the same issue with Drupal 7?
Comment #184
mikeytown2 CreditAttribution: mikeytown2 commented@mdupont
if you look at the links in my comment on #119; in D7 this issue is fixed, for firefox. According to comment #180 Google Chrome needs
no-store
to be set in the Cache-Control header.D6:
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
D7:
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Comment #185
Shai CreditAttribution: Shai commentedsubscribe
Comment #186
dankh CreditAttribution: dankh commentedsubscribe
Comment #187
a.siebel CreditAttribution: a.siebel commentedPatch #63 works for me :-)
Comment #188
eduardo barros CreditAttribution: eduardo barros commentedi have patched with #63 three months ago and it seems ok. thank you mithy(#61) and matt!
Comment #189
jthomasbailey CreditAttribution: jthomasbailey commentedsubscribing
Comment #190
TheMentat CreditAttribution: TheMentat commentedsubscribing
Comment #191
armanschwarz CreditAttribution: armanschwarz commentedWhy isn't this committed to core?
Comment #192
HOKATA CreditAttribution: HOKATA commentedsubscribing
Comment #193
Damien Tournoud CreditAttribution: Damien Tournoud commentedAs far as I know, this is not a browser issue, but rather an issue of some silly hosting environment that caches the pages and bypass Drupal completely.
If anyone can give us access to an hosting environment that shows this behavior (or at least full HTTP traces), we might be able to move forward on this issue.
Comment #194
vorapoap CreditAttribution: vorapoap commentedStill not changed in drupal6.20
Comment #195
Damien Tournoud CreditAttribution: Damien Tournoud commentedSee #193.
Comment #196
fax8 CreditAttribution: fax8 commentedDamien, get in touch with me. I'm able to give you ssh access to my server which has this problem.
Comment #197
greenwork CreditAttribution: greenwork commentedsubscribe.. Same problem but my host has "assured me" they do not have scripts running on their side for caching. Anyways I may try to do patch in #61 since this problem has caused me to turn off normal caching for over a year now and my performance doubles if I have normal caching on
Comment #198
dpatte CreditAttribution: dpatte commentedpatch #63 has worked for me since August without any known side-effects
Comment #199
emdalton CreditAttribution: emdalton commentedDid you apply the patch from #63 to D6? Besides the problem with logouts failing, I also seem to be experiencing a very odd problem with pages losing theming, but only some pages from a specific browser-- if I view the same page from another install of the same browser it views correctly. In fact, if I view the page via an alternate URL (e.g. without the www prefix) it views correctly. Might this patch fix that?
Comment #200
mikeytown2 CreditAttribution: mikeytown2 commented@emdalton
There is a chance that this could fix the missing CSS file.
Comment #201
Janbur CreditAttribution: Janbur commentedDamien, I'm having this problem as well and can work with you via WebEx or GoToMeeting if you are interested. For now, I have disabled the cache entirely on both my development and production sites. Let me know if you are interested.
Comment #202
HnLn CreditAttribution: HnLn commentedsub
Comment #203
AnybodyWill there be a general fix for this problem in core of D6 in one of the next releases or is this seen as by design / no drupal problem?
subscribe.
Comment #204
ChrisLaFrancis CreditAttribution: ChrisLaFrancis commentedSubscribing.
Comment #205
pilotget CreditAttribution: pilotget commentedI just moved a working installation from bluehost.com to a VPS and the problem started arising. So the hosting environment definitely plays a major role.
Here are the major differences I surmised between the working and non-working hosting environments. Except for the hosting environment, everything is the same. Hopefully this helps:
WORKING (Bluehost.com):
Operating System: (??) Bluehost's (I think CentOS... don't know the version. Kernel is 2.6.32-28.6)
PHP:5.2.16, APC not installed, Suhosin Patch 0.9.7, PHP5 Handler: FCGI
NOT WORKING (my VPS):
Operating System: CentOS 5.5
PHP: 5.2.16, Zend Scripting Language Engine, PHP APC, Suhosin Not Installed, PHP5 Handler: suphp
WORKING (my local test server):
Operating System: Ubuntu 10.10
PHP: 5.3.3, Zend Scripting Language Engine, PHP APC, Suhosin Not Installed
***UPDATE: Problem fixed!!!***
I changed the php 5 handler on my VPS from suphp to fcgi and the problem disappeared!
I hope this helps others with the same problem.
Comment #206
pilotget CreditAttribution: pilotget commentedI just wanted to add that I did extensive testing over the last few days. I tried multiple combinations of php_apc, php 5.2/php 5.3, suphp, and fcgi. The problem is definitely linked to suphp. As soon as I switch from suphp to fcgi, the problem disappears in all configurations.
Comment #207
mikeytown2 CreditAttribution: mikeytown2 commented@pilotget
What are the headers sent out by the 2 different configurations (suphp/fcgi)?
Comment #208
fax8 CreditAttribution: fax8 commented@pilotget that may be the cause of this issue.. if I recall correctly, also Site5, is running suphp and I'm experiencing this issue on their servers.
Comment #209
Shai CreditAttribution: Shai commentedGreat work @pilotget!
I'm running suphp on a server that experiences this problem.
Does anyone have ideas on how to proceed given this new knowledge?
Shai Gluskin
Comment #210
pilotget CreditAttribution: pilotget commented@mikeytown2
By "what are the headers" are you asking what is between the <head> and </head> tag in the response, or are you asking something else?
I'm happy to switch between the 2 environments and post the headers here if it would help.
Comment #211
fax8 CreditAttribution: fax8 commentedHTTP Headers .. you can use live http headers for firefox to see them nicely
Comment #212
pilotget CreditAttribution: pilotget commentedThanks @fax8
I will download the live http headers for firefox and will post the results here.
Since switching from suphp to fcgi and back entails some downtime, I can do it over the weekend.
Comment #213
pilotget CreditAttribution: pilotget commentedI ran the tests again. As expected, under suphp the problem appeared again. As soon as I switched back to fcgi, the problem disappeared. Attached are the headers from my page using both fcgi and suphp. I hope this helps.
Note: the http header info was slightly different in Chrome/Developer Tools and Firefox/Firebug so I copied the information from both browsers into the files.
Also: the problem was observed in both Chrome and Firefox when I was using suphp.
The files are as follows:
Comment #214
mikeytown2 CreditAttribution: mikeytown2 commentedInteresting. The cache control header for the one that works is
The patch in #86 is basically replicating this desired output.
The one with the problem observed was a 304. You need to get a 200 in order to do this properly. Ctrl-F5 should generate a 200 response.
Comment #215
pilotget CreditAttribution: pilotget commentedI apologize for sending http headers with the wrong status code. I changed back to suphp, observed the problem, and used shift-refresh to get a 200 response. The headers are attached.
Comment #216
Shai CreditAttribution: Shai commentedThanks so much to @pilotget and @mikeytown2.
Are we at the point yet where you would recommend to folks running D6 on suphp setups to apply the patch in #86?
Shai
Comment #217
pilotget CreditAttribution: pilotget commentedUnfortunately, I don't know enough about headers to make a suggestion. Perhaps mikeytown2 can weigh in. I would think if patch #86 does the right thing, shouldn't it be implemented as a core patch?
Comment #218
Shai CreditAttribution: Shai commentedAlright... I just applied patch #86 to one site. Seems to have fixed the login-linger issue... I'll keep my eye out for any abnormal behavior. Do note, I had to apply the patch manually since the line numbers from the patch are no longer correct. But it's a very simple two line patch so that was not a big deal.
Comment #219
fax8 CreditAttribution: fax8 commentedOk, now we know what is happening and how to fix this. Any maintainer around willing to review the patches?
Comment #220
Damien Tournoud CreditAttribution: Damien Tournoud commentedMy guess is that the SuPHP SAPI is actually validating the headers and chokes on the completely invalid
store
header (which does not exist at all in the HTTP specification). Could you try just removing thestore
header (we *don't* wantno-store
)?Comment #222
AlonGoldberg CreditAttribution: AlonGoldberg commentedSubscribe.
Comment #223
davipilot CreditAttribution: davipilot commentedSubscribe
Comment #224
Mackee CreditAttribution: Mackee commentedOn my site, what I observed was that when I used long-polling for drupalchat, this issue occurs. If I turned it to ajax it fixes the issue. But right now drupalchat only works on my site when I use long-polling.
Still #61 fixed the issue.
Comment #225
lelizondo CreditAttribution: lelizondo commentedI'm still having serious issues with this.
This is how you can probably reproduce it:
1. Install two sites, www.example.com and subdomain.example.com
2. Install backery module and configure with the instructions module.
I also have Pressflow and Varnish working on my server but I don't think this is a problem with Pressflow/Varnish. I also don't think this is an issue with backery, this is about headers / cookies / sessions, who knows, I'm not an expert.
Comment #226
mikeytown2 CreditAttribution: mikeytown2 commented@lelizondo
Pressflow has this patch applied to it; if your using pressflow and having this issue, your barking up the wrong tree most likely.
Comment #227
lelizondo CreditAttribution: lelizondo commentedAny possible solutions then?
Comment #228
Anonymous (not verified) CreditAttribution: Anonymous commentedThe patch in 86 works perfectly on my suPHP server (manual patching at this point).
Why isn't this in core yet? Does it break other implementations of PHP?
Comment #229
Mackee CreditAttribution: Mackee commentedPatch 86 works for me as well. Thanks!
------------------------------------
Update:
The patch works but if i keep on pressing refresh/reload sometimes it still log me in.
Comment #230
diego.pasc CreditAttribution: diego.pasc commentedI'm also having this problem since I installed DrupalChat with LongPolling enabled (as in comment #224)
Patch #61 seems to work.
Comment #231
yub_yub CreditAttribution: yub_yub commentedsubscribing
Comment #232
TuWebO CreditAttribution: TuWebO commentedI have the same problem using drupal 6.20,
The weird thing is that I was developing in webenabled platform and everything seems to work fine (at least I didn´t notice this strange behaviour).
Then I backup the site from webenabled and migrated it to my local server (in my computer) for making some other testing.
When I went back to webenabled platform I started to realize this problem (I am not sure if this was happening before).
Could this migration to my local server be related to this issue? (Don´t think so, but just in case)
I mean, some else had migrated the site to his local server and afterwards started to have this problem?
Comment #233
squinternata CreditAttribution: squinternata commentedi have the same problem i think with drupal 6.22
i m using oai2forcck module and i need to display xml content but when you are not logged in it stores in cache_page headers "Content-Type: text/html;" so it display uncorrect format.
let me know please
for the moment i disabled cache but i need to enable it.
thanks
A
Comment #234
hapydoyzer CreditAttribution: hapydoyzer commentedUpdated patch from comment #108 for Drupal 5.
Comment #235
Yurkos CreditAttribution: Yurkos commentedsame here - drupal 6.22, double login and double logout appearance...
Comment #236
crifi CreditAttribution: crifi commentedThis problem seems to be fixed in Drupal 7 with this commit http://drupalcode.org/project/drupal.git/commit/526401c4c8f7e1a8126c4810... of this issue #147310: Implement better cache headers for reverse proxies
Comment #237
chx CreditAttribution: chx commentedComment #238
grahamvalue CreditAttribution: grahamvalue commentedReopening the issue.
This problem still exists with Drupal core 6.26, on both Safari and Chrome (haven't yet checked Firefox).
It happens only on Drupal websites, so it can't be an issue with the network or hosting.
All other websites work fine on the same browsers and network.
The blocks in the sidebar are rendered from the cache, even after logging out; thus giving the false impression that the user is still logged in.
Once the user visits a page he has not visited while logged in, the sidebar gets generated newly and then all the other pages behave fine too.
I'm surprised that such a major bug in the core logout functionality has not been fixed for 5 years.
Comment #239
geneatwell CreditAttribution: geneatwell commentedSubscribe.
Comment #240
srees CreditAttribution: srees commentedSubscribe. This issue was recently reported to us for a D6 site, Firefox only. Applying patches from #63 and #86 did NOT fix in our situation. Appeared to, for a day, but it came back. #108 does seem to work, I'll have to watch it over the next few days...
Dang, spoke too soon....still broken for me. Also, clearing cache on logout did not work either.
Comment #241
mfuggle CreditAttribution: mfuggle commentedSubscribe - I am experiencing this same issue on a Drupal 6.26 site. I have caching turned off to prevent the problem occurring but I need a solution since I wish to turn caching on. I have read this thread but am not sure what patch, if any to apply. It seems that this was first reported in December, 2007 yet is still lurking around as a problem. It seems to me that it is a non-trivial issue.
Cheers
Martin Fuggle
Comment #242
awasson CreditAttribution: awasson commentedMartin,
I think it's just being neglected since D6 is near the end of the road, D7 is the standard and D8 is on the horizon.
I still have a half dozen or so active D6 sites so I have used matt@antinomia's fix that is illustrated in Post #49.
It is the working part of a module and is quite complete. All it needs is an info file. I've been using it for quite some time under the name cacheclear. Just make a directory called cacheclear and inside it put two files that share the same name:
cacheclear.info:
cacheclear.module:
Upload those to sites/all/modules (or wherever you have your contributed modules) and activate.
Comment #243
mfuggle CreditAttribution: mfuggle commentedVery many thanks - that works like a charm. This issue has been causing me concern for quite a while and I never managed in the past to get the right Google search criteria to find a solution. I am much indebted to you for replying to my post.
Regards
Martin Fuggle
Comment #244
Vako CreditAttribution: Vako commentedThank you awasson.
I had this issue for months and your solution worked perfect for me!
This code should be in Drupal core.
Comment #245
David Hernández CreditAttribution: David Hernández commentedThis issue still exists on D7. Here is a patch that should fix it, rerolled from the patch at #87
Comment #246
David Hernández CreditAttribution: David Hernández commentedOops, missed the patch. Now checking if this issue is also in D8.
Comment #255
David Hernández CreditAttribution: David Hernández commentedSame issue on Drupal 8. Attached patch. I'm not sure if it's the correct solution for Drupal 8 due to my lack of knowledge of D8.
Comment #257
Damien Tournoud CreditAttribution: Damien Tournoud commented@David Hernández: If you think there is a bug here, you will have to explain what it is. `no-store` is not desirable. Could you explain the behavior that you see and how it differs from the behavior that you expect?
Comment #258
David Hernández CreditAttribution: David Hernández commented@Damien Tournoud, is the issue reported in the original post. Some browsers don't respect the "no-cache" and the browser caches a page as an authenticated user and servers them when you have logged out. I've had this issue in Drupal 7 with some versions of Safari (the last version, for example). I haven't tested it in Drupal 8, but as it's sending the same HTTP header as Drupal 7, I'm certainly sure that the same behaviour will happend.
Comment #259
David Hernández CreditAttribution: David Hernández commentedUpdated D7 version, to fix the tests.
Comment #261
Damien Tournoud CreditAttribution: Damien Tournoud commented@David: This issue is a massive mixed-bag of people conflating a lot of different issues. Please open a new issue with details of what you are seeing:
- Precise reproducible scenario
- Server infrastructure and version of the different component
- Affected browsers
- Request and response headers captures from the Network log
Note that we have an issue open for Safari in #1910178: Safari shows cached pages to authenticated users (from the browser cache) when a maximum cache age is set, but it seems to be the opposite of what you are trying to fix.
Comment #262
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedJust in case anybody tries this patch: It seems to me that while it fixes the problem "user who just logged out sees a previously cached page [which is delivered from the browser cache!]" it introduces a new problem, namely "varnish doesn't cache any Drupal generated HTML anymore".
Comment #265
izmeez CreditAttribution: izmeez commentedWith respect to comments #261 and #262 this is a re-roll of the patch in #259 against the current 7.x git repo for those that need it.
Comment #266
izmeez CreditAttribution: izmeez commentedThis is a re-roll of patch in #259 against current 7.x git repo for drupal 7.40
Comment #267
Cyberflyer CreditAttribution: Cyberflyer commentedThis issue of failing to fully log out has been vexing me for some time.
I'm running Drupal Commons and CiviCRM on Drupal 6.37, PHP 5.6.15. Could not get a clean log-out on FireFox 43.0.4.
The solution in #242 solved this problem for me. No hacking core, cache is cleared, system behaves as expected.
Am posting here as a huge thank you to the developer and as a pointer for others Googling for the solution to:
Drupal session will not log out properly.
Comment #268
izmeez CreditAttribution: izmeez commentedA custom module as suggested in #242 would be great for Drupal 7 but I can't seem to get it to work. It looks simple enough but after logout authenticated pages are still visible in firefox with the browser back button. I'm also puzzled how this code can clear the browser cache.