Firefox doesn't revalidate some cached pages due to wrong HTTP headers

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

Does 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?

What sort of internet connection are you on? Satellite by chance?

What sort of internet connection are you on? Satellite by chance?

I'm on verizon cable internet.

Does the page fix itself after holding the shift key while reloading in Firefox?

The page fixes itself when hitting ctrl+shift+f5 to clear cache and refresh the page.

Are all browsers affected?

Firefox 2 and IE7 seem to be affected.

Does this happen when Drupal's page cache is off?

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.

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

Also, I am having this problem with 5.6.

I 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]

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

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

We 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?

I'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.)

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

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.

Nothing 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?)

same 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

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

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

I'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

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

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

confirming 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

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

I have this exact problem too.

Is there any resolution yet?

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

The 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

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

OK, it was working fine in IE6 so I restarted, cleared the firefox cache and my site cookies and all seems to be working again.

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

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

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

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

tracking - having same issue seems like

to recreate issue -

• select Performance -> Caching mode: -> Normal (recommended, no side effects)
• Entered site as Authenticated user role (in my case editor with editing permissions)
• Using User Login Block and login toboggan block Block Type link
• Try to Logout it puts you in a loop not able to determine if you are logged in or out.
• Able to get out of the loop by going to example.com/user (typing directly in the Browser Url address Bar) and signing in as Super User

Also

• Problem stops when disabling Cache Mode

Update:

• Thought i was able to get a resolution ...When I recreated my steps - without a login toboggan block i do not seem to have any of the issues....but came back after further testing

This 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

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

Is 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

It happens on Drupal 5.7 too but only for FireFox. IE performs well.

Regards

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

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

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

subscribing

having this problem with 5.9

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

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

FWIW, 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]

Response 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?

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

1. Could it be related it to or caused by the individual themes. Does using Garland solve this problem? I can't recall having this problem using Garland
2. I have yet to tell my Webhost to change to PHP 5 - caused I don't know what problems that would cause. Would the fact that my server is running PHP 4 vs PHP 5 be the caused of the problem?

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

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

I 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]

matt@antinomia,

So just to clarify...to use your work around....

1. You created an arbitrarily named module something like "mymodule.module" with the following code and put it in custom modules folder
2. sit back and relax

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?

Putting just that code in my view header seems to have fixed it for me. I still have cache enabled.

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

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

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

hey thanks guys - that helps out a lot to clarify - i am suffering from information overload with everything:) so that helped out a lot.

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

Maybe this is related to our hosting? I am using hostgator shared hosting. How about the rest of you?

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

I 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

Ya 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

This is a critical error that makes Drupal unusable.

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

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

I 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

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

@ mithy

Thank you, it appears with immediate/short term testing that it works. Will continue to test.

Using normal caching, just FYI.

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

Attachment	Size
bootstrap_cache_control_no_store.patch.txt	521 bytes

I'm sorry what file is this patch applied to? Thanks

matt: okay great thx again

@henns20: includes/bootstrap.inc

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

Might not be an acceptable solution because it hacks a core file, but perfectly solves my problem!

@ mithy : Thanks a lot!!!!

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

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

The problem is still there for 6.9

I 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:

• Issue affects Firefox, SeaMonkey, and Safari, but not IE.
• It affects 5.x and 6.x (for every version I have ever used...).
• It is definitely related to Drupal's cache (i.e., it occurs only when caching is on; I only tried "normal", but I assume "aggressive" would have the same problem).
• It is actually rather easy to reproduce the essential problem, given that you can control what is going on (see steps below).
• It is a Drupal core problem and occurs without any third-party modules (contrary to some previous suggestions).

Steps to reproduce (at least for me, on a site with no other traffic):

1. Given a basic Drupal site, and using an affected browser (in my case, Firefox 3.0.5)...
2. Clear Drupal's cache tables.
3. Go to admin/settings/performance and set caching mode to "Normal" and save.
4. Log out.
5. Clear the browser's cache.
6. Log in.
7. Explicitly visit your front page.
8. Immediately log out again.

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?

subscribe

Have applied the #61 fix, problem solved:)

Seems to have worked for me too. Thank you.

#61 worked for me.

hey....#61 worked for me as well...thanks

the comments in #70 notwithstanding, there is a patch to this issue in #63 and it needs review.

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

Subscribe the same problem with drupal 6.9

I 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

Same here on 6.10: cache->normal.

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

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

Attachment	Size
bootstrap_cache_control_no_store2.patch (For Drupal 5.*)	475 bytes

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

Having same troubles in 6.11 for my homepage, #61 saved it

Cache (Normal)

I'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 in drupal_page_header(), I've also found it necessary to add this directive to drupal_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.

Attachment	Size
login_linger.patch	1.1 KB

Also find an (untested) patch that does the same for D7 (latest HEAD).

Attachment	Size
login_linger_d7.patch	1.44 KB

subscribing

I 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

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

The correct fix is to remove the "store" part (that doesn't exist). If someone could roll a patch, it would be awesome.

Damien,

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

I 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

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

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

Attachment	Size
jamesan_197786-95-D5.patch	715 bytes
jamesan_197786-95-D6.patch	713 bytes

We don't want "no-store". I'm pretty sure simply removing "store" works. @JamesAn, could you do your own testing?

Hmm.. 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... >_<"

JamesAn, 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

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

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

I 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

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

Damien,

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