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)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wolfderby’s picture

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.

drumm’s picture

Status: Active » Postponed (maintainer needs more info)

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?

criznach’s picture

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

wolfderby’s picture

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

I'm on verizon cable internet.

wolfderby’s picture

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.

paulvantuyl’s picture

Version: 5.3 » 5.6

Is there any way to only have

<?php
cache_clear_all($url, 'cache_page');
?>

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

paulvantuyl’s picture

Version: 5.6 » 5.3

Also, I am having this problem with 5.6.

Ugljesa’s picture

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]

psynaptic’s picture

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.

cburschka’s picture

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.

psynaptic’s picture

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?

cburschka’s picture

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

end user’s picture

Version: 5.3 » 5.7

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.

ttosttos’s picture

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.

intent’s picture

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

parrottvision’s picture

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

glass.dimly’s picture

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.

paulvantuyl’s picture

Version: 5.7 » 5.6

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.

cdemetriadis’s picture

Version: 5.6 » 5.7

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

introfini’s picture

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

gash-1’s picture

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.

geek-merlin’s picture

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

criznach’s picture

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

bigsend’s picture

Status: Postponed (maintainer needs more info) » Active

I have this exact problem too.

Is there any resolution yet?

cmillet1’s picture

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.

bigsend’s picture

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

awolfey’s picture

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.

awolfey’s picture

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.

cmillet1’s picture

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.

cmillet1’s picture

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

cmillet1’s picture

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.

joncup’s picture

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-

henns20’s picture

Version: 6.x-dev » 5.7
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

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
memenode’s picture

Version: 5.7 » 5.8

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?

cache_clear_all($url, 'cache_page');

Thanks

memenode’s picture

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.

bigsend’s picture

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

pramudya81’s picture

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

Regards

watbe’s picture

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.

mjourney2’s picture

Version: 5.8 » 6.3

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.

Damien Tournoud’s picture

Version: 6.3 » 6.x-dev
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

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.

tknospdr’s picture

subscribing

joncup’s picture

Version: 6.x-dev » 5.9

having this problem with 5.9

Damien Tournoud’s picture

Version: 5.9 » 6.x-dev

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

mjourney2’s picture

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.

matt@antinomia’s picture

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]

paulvantuyl’s picture

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?

henns20’s picture

Version: 5.7 » 6.x-dev
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

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

walker2238’s picture

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.

matt@antinomia’s picture

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!

<?php
function my_module_user($op, &$edit, &$user_edit, $category = NULL) {
  if ($op == 'logout') {
    global $base_root;
    cache_clear_all($base_root .'/', 'cache_page');
  }
}
?>

[EDIT] The above code does seem to improve the situation but does not workaround the bug all of the time. [/EDIT]

henns20’s picture

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

psynaptic’s picture

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.

matt@antinomia’s picture

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

henns20’s picture

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

B.P.B’s picture

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.

B.P.B’s picture

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

watbe’s picture

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 .

pramudya81’s picture

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

henns20’s picture

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

luckyday13’s picture

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.

cwittusen’s picture

Version: 6.x-dev » 5.9

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

mithy’s picture

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.

paulvantuyl’s picture

@ mithy

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

Using normal caching, just FYI.

matt@antinomia’s picture

Version: 5.9 » 5.x-dev
Component: user system » base system
Status: Postponed (maintainer needs more info) » Needs review
FileSize
521 bytes

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.

henns20’s picture

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

matt: okay great thx again

matt@antinomia’s picture

@henns20: includes/bootstrap.inc

Perceptum-1’s picture

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

$usercount = db_result(db_query("select count(uid) as numu from users where status=1"));

the admin user was always logged in, regardless of the browser, or computer. Once I changed it to

$reso = db_query("select count(uid) as numu from users where status=1");
$cnto = db_fetch_object($reso);

the admin user was not automatically logged in on that page. Im not sure if this is a bug or expected behaviour.

terabitez’s picture

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

@ mithy : Thanks a lot!!!!

philpro’s picture

Version: 5.x-dev » 6.6

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.

ShannonK’s picture

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

skyredwang’s picture

Version: 6.6 » 6.9
Status: Needs review » Active

The problem is still there for 6.9

jsheffler’s picture

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?

lelizondo’s picture

subscribe

farald’s picture

Have applied the #61 fix, problem solved:)

JonoB’s picture

Seems to have worked for me too. Thank you.

superdorx’s picture

Title: Drupal return "Not modified" response to anonymous even if his browser cache contain page from authenticated user. » User Log-out Problem
Version: 6.x-dev » 6.9
Status: Closed (won't fix) » Active
Issue tags: -cache, -browsers
pramudya81’s picture

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

Les Lim’s picture

Title: User Log-out Problem » authenticated user navigation items linger after logout
Status: Active » Needs review

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

pramudya81’s picture

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.

ldbl’s picture

Subscribe the same problem with drupal 6.9

pramudya81’s picture

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

losco’s picture

Same here on 6.10: cache->normal.

Ivan Zugec’s picture

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.

hapydoyzer’s picture

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.

pramudya81’s picture

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

iamwhoiam’s picture

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

Cache (Normal)

Jaza’s picture

Assigned: Unassigned » Jaza
FileSize
1.1 KB

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.

Jaza’s picture

FileSize
1.44 KB

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

gonzalez_ea’s picture

subscribing

Damien Tournoud’s picture

Version: 6.9 » 6.x-dev
Assigned: Jaza » Unassigned
Status: Needs review » Needs work

I can reproduce on 6.x, on Firefox 3.0.10. 7.x is not affected.

Drupal 7 uses:

Cache-control: no-cache, must-revalidate, post-check=0, pre-check=0

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

izmeez’s picture

Issue tags: -Novice

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.

Damien Tournoud’s picture

Issue tags: +Novice

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

izmeez’s picture

Issue tags: +Novice

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

izmeez’s picture

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

webengr’s picture

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.

JamesAn’s picture

Status: Needs work » Needs review
FileSize
713 bytes
715 bytes

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.

Damien Tournoud’s picture

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

JamesAn’s picture

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

izmeez’s picture

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

Damien Tournoud’s picture

Title: authenticated user navigation items linger after logout » Firefox don't revalidate some cached pages due to wrong HTTP headers

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

JamesAn’s picture

Title: Firefox don't revalidate some cached pages due to wrong HTTP headers » Firefox doesn't revalidate some cached pages due to wrong HTTP headers

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

izmeez’s picture

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

TapSkill’s picture

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.

izmeez’s picture

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

netclickonline’s picture

It seems the patch has resolved the issue. I was experiencing this problem as well. It's working fine now in Firefox.

Thanks,
Sameer

JamesAn’s picture

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

hapydoyzer’s picture

@JamesAn, jamesan_197786-105-D5.patch is not working for my Firefox 3.0.10
Only patch with "no-store" works for me.

JamesAn’s picture

Thanks for testing it, hapydoyzer.

Can we RTBC patches in #95, since those in #105 don't work?

hapydoyzer’s picture

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

  1. As logged in user you request / page. Last-Modified header is set to current time. E.g 12:00. Page is saved in local cache.
  2. When you hit "logout" your session is now deleted and you are anonymous
  3. logout then redirects you to / page.
    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)
  4. In this time Drupal cannot tell if you are been logged in user one second ago or you always be an anonymous and never 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

hapydoyzer’s picture

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

hapydoyzer’s picture

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

hapydoyzer’s picture

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

hapydoyzer’s picture

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

hapydoyzer’s picture

Title: Firefox doesn't revalidate some cached pages due to wrong HTTP headers » Drupal return "Not modified" response to anonymous even if his browser cache contain page from authenticated user.
Issue tags: -Novice +cache, +browsers

This 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 :)

PatW’s picture

subscribing

fletch11’s picture

subscribe

hapydoyzer’s picture

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

m.a.king’s picture

I Just started testing the patch in #108 for D6 and everything seems good so far (only checked in FF 3.5 and IE8).
Thanks!

mikeytown2’s picture

Is 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

izmeez’s picture

Looking 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

Damien Tournoud’s picture

Status: Needs review » Postponed (maintainer needs more info)

I 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_modified_since = isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) ? stripslashes($_SERVER['HTTP_IF_MODIFIED_SINCE']) : FALSE;
  $if_none_match = isset($_SERVER['HTTP_IF_NONE_MATCH']) ? stripslashes($_SERVER['HTTP_IF_NONE_MATCH']) : FALSE;

  if ($if_modified_since && $if_none_match
      && $if_none_match == $etag // etag must match
      && $if_modified_since == $last_modified) {  // if-modified-since must match
    header('HTTP/1.1 304 Not Modified');
    // All 304 responses must send an etag if the 200 response for the same object contained an etag
    header("Etag: $etag");
    return;
  }

  // Else, return a whole new page.

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.

AndraeRay’s picture

Status: Closed (won't fix) » Postponed (maintainer needs more info)

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

cache_clear_all($url, 'cache_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.

Damien Tournoud’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

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

m.a.king’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

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

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20090909 Fedora/3.5.3-1.fc11 Firefox/3.5.3 FirePHP/0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://example.com/content/foo
Cookie: SESS...;
__utma=...;
__utmz=...;
__utmb=...
If-Modified-Since: Fri, 18 Sep 2009 03:04:06 GMT
Cache-Control: max-age=0

HTTP/1.x 304 Not Modified
Date: Fri, 18 Sep 2009 03:10:17 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7a Phusion_Passenger/2.2.4 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Etag: "bb1efe2beff05e2a12307d337dfed546"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate

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.

NedFlanders’s picture

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

function mymodule_drupal_page_header() {

  header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
  header("Last-Modified: ". gmdate("D, d M Y H:i:s") ." GMT");

  //header("Cache-Control: store, no-cache, must-revalidate");
  header("Cache-Control: no-store, no-cache, must-revalidate");

  header("Cache-Control: post-check=0, pre-check=0", FALSE);

}

But that didn't seem to work....

mikeytown2’s picture

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

m.a.king’s picture

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

mikeytown2’s picture

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

nelslynn’s picture

Experiencing this issue with Drupal 6.14. Will try the mod_headers solution.

danreb’s picture

Me too with Drupal 6.14

Subscribe...

lelizondo’s picture

Tried 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

mikeytown2’s picture

Think I might have figured out a way to do this without hacking core. Set these 2 meta tags

<meta http-equiv="Cache-Control" Content="no-cache" />
<meta http-equiv="Expires" Content="0" />

Any testing would be appreciated.

John Pitcairn’s picture

Hmm. Subscribing.

Damien Tournoud’s picture

Please also see #550488: Turn off mod_expires for all .php files, which might help in some server configurations.

mikeytown2’s picture

Heads up I am able to reproduce this bug finally after adding these lines to the bottom of my htaccess file

Header unset ETag
FileETag none

People would be adding these in due to yslow's recommendation to remove etags most likely.

Damien Tournoud’s picture

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

Gerben Zaagsma’s picture

subscribing

HS’s picture

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

mikeytown2’s picture

portulaca’s picture

subscribing

HS’s picture

I don't know how to patch :(

mikeytown2’s picture

rc2020’s picture

subscribing

hapydoyzer’s picture

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

X-Powered-By: PHP/5.2.10
X-debug-select: DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE at Fri, 29 Jan 2010 13:11:21 GMT
Last-Modified: Fri, 29 Jan 2010 07:59:44 GMT
ETag: "ea062712517c942baf47d23594e4f68a"
Expires: Sun, 19 Nov 1978 05:00:00 GMT',
Cache-Control: must-revalidate
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8

And what server returns:

Server: nginx/0.7.63
Date: Fri, 29 Jan 2010 13:11:21 GMT
Content-Type: text/html; charset=utf-8
Cache-Control: must-revalidate
Expires: Sun, 19 Nov 1978 05:00:00 GMT
X-debug-select: DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE at Fri, 29 Jan 2010 13:10:08 GMT
X-Powered-By: PHP/5.2.10
Last-Modified: Fri, 29 Jan 2010 07:59:44 GMT
Content-Encoding: gzip

Request headers:

Host	: <removed>
User-Agent	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language	ru,en-us;q=0.7,en;q=0.3
Accept-Encoding	gzip,deflate
Accept-Charset	windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive	600
Connection	keep-alive
Referer: <removed>
Cookie: <removed>
If-Modified-Since: Fri, 29 Jan 2010 07:59:44 GMT

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.

hapydoyzer’s picture

Title: User Log-out Problem » Drupal return "Not modified" response to anonymous even if his browser cache contain page from authenticated user.
Version: 6.9 » 6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +cache, +browsers

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

drubb’s picture

IMHO 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

mikeytown2’s picture

@BorisB
Renable your etags; odds are you disabled them in your htaccess file.

portulaca’s picture

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

Damien Tournoud’s picture

Status: Closed (won't fix) » Active

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

rc2020’s picture

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

HS’s picture

The issue is indeed that we use the invalid 'store' tag. Changing that to 'no-store' completely fixes the issue.

Thanks 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!

Alun’s picture

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

izmeez’s picture

@Damien #149
Thanks. Does this support Mithy's solution in #61 as the right way to fix?

Izzy

Ela’s picture

subscribing

webservant316’s picture

subscribing

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.

webservant316’s picture

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

hassansr’s picture

the fix that worked for me was to modify .htaccess as in this thread

http://drupal.org/node/77106

hassansr’s picture

the fix that worked for me was to modify .htaccess as in this thread

http://drupal.org/node/77106

usera’s picture

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

dpatte’s picture

subscribe

maomaohuhu’s picture

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

  • login , wander around, visit some pages...
  • logout
  • come back to the pages previously visited : Ooops, it looks like I am still logged in !

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.

header("Cache-Control: store, no-cache, must-revalidate");
===> header("Cache-Control: no-store, no-cache, must-revalidate");
in function drupal_page_header() in ./include/bootstrap.inc

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 :

HTTP/1.1 200 OK
Date: Fri, 07 May 2010 16:07:27 GMT
Server: Apache/2.2.X (OVH)
X-Powered-By: PHP/5.2.13
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
Last-Modified: Fri, 07 May 2010 16:07:27 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2850
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

2°) LOGGED OUT ( same page , after being logged out )

HTTP/1.1 304 Not Modified
Date: Fri, 07 May 2010 16:08:28 GMT
Server: Apache/2.2.X (OVH)
Connection: Keep-Alive
Keep-Alive: timeout=5, max=97
Etag: "69276f7602e9ee0ebef2d7c76daa60b3"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate

Hmmm.... are we supposed to hack core until D7 comes along ?

bluedrup’s picture

Thanks 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

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

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

mikeytown2’s picture

My 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

david.a.king’s picture

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

fax8’s picture

Status: Closed (won't fix) » Active

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

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

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

fax8’s picture

@Damien I'm contacting you offsite to give you access to our server

shyam541’s picture

subcribing....

sleepingmonk’s picture

subscribing

phil_esq.’s picture

Subscribe.

gn0rt0n’s picture

Subscribe

jjwhitney’s picture

subscribing

roald’s picture

Same problem - subscribing

roald’s picture

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

/**
 * Implementation of hook_user()
 */

function cacheclear_user($op, &$edit, &$account, $category = NULL) {
  if ($op == 'logout') {
    cache_clear_all('*', 'cache_page', TRUE);
  }
}

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.

mikeytown2’s picture

Status: Closed (won't fix) » Active

Video helps a lot; this needs another look

fax8’s picture

Great 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)

bnavasky’s picture

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

Cyberwolf’s picture

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

Cyberwolf’s picture

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

bnavasky’s picture

Patch from #63 worked for me. Haven't observed any negative consequences.

dpatte’s picture

ditto #181, #63 has worked for me for the last few months

mdupont’s picture

Title: Drupal return "Not modified" response to anonymous even if his browser cache contain page from authenticated user. » Some browsers will cache pages even when header Cache-control: no-cache is set

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

mikeytown2’s picture

@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

Shai’s picture

subscribe

dankh’s picture

subscribe

a.siebel’s picture

Patch #63 works for me :-)

eduardo barros’s picture

i have patched with #63 three months ago and it seems ok. thank you mithy(#61) and matt!

jthomasbailey’s picture

subscribing

TheMentat’s picture

subscribing

armanschwarz’s picture

Why isn't this committed to core?

HOKATA’s picture

subscribing

Damien Tournoud’s picture

Title: Some browsers will cache pages even when header Cache-control: no-cache is set » Some servers / browsers will cache pages even when header Cache-control: no-cache is set
Status: Active » Postponed (maintainer needs more info)
Issue tags: -cache, -browsers

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

vorapoap’s picture

Version: 6.x-dev » 6.20

Still not changed in drupal6.20

Damien Tournoud’s picture

Version: 6.20 » 6.x-dev

See #193.

fax8’s picture

Damien, get in touch with me. I'm able to give you ssh access to my server which has this problem.

greenwork’s picture

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

dpatte’s picture

patch #63 has worked for me since August without any known side-effects

emdalton’s picture

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

mikeytown2’s picture

@emdalton
There is a chance that this could fix the missing CSS file.

Janbur’s picture

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

HnLn’s picture

sub

Anybody’s picture

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

ChrisLaFrancis’s picture

Subscribing.

pilotget’s picture

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

pilotget’s picture

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

mikeytown2’s picture

@pilotget
What are the headers sent out by the 2 different configurations (suphp/fcgi)?

fax8’s picture

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

Shai’s picture

Great 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

pilotget’s picture

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

fax8’s picture

HTTP Headers .. you can use live http headers for firefox to see them nicely

pilotget’s picture

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

pilotget’s picture

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

  • headers-fcgi-home.txt: http headers from the first test (on fcgi, before switching to suphp... working system)
  • headers-suphp-home.txt: http headers from the second test (after switching to suphp... problem observed)
  • headers-fcgi-homev1.txt: http headers from the third test (after switching back to fcgi... problem disappeared)
mikeytown2’s picture

Interesting. The cache control header for the one that works is

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0

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.

pilotget’s picture

FileSize
2.19 KB

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

Shai’s picture

Thanks 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

pilotget’s picture

Unfortunately, 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?

Shai’s picture

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

fax8’s picture

Status: Postponed (maintainer needs more info) » Needs review

Ok, now we know what is happening and how to fix this. Any maintainer around willing to review the patches?

Damien Tournoud’s picture

My 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 the store header (we *don't* want no-store)?

Status: Needs review » Needs work

The last submitted patch, login_linger.patch, failed testing.

AlonGoldberg’s picture

Subscribe.

davipilot’s picture

Subscribe

Mackee’s picture

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

lelizondo’s picture

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

mikeytown2’s picture

@lelizondo
Pressflow has this patch applied to it; if your using pressflow and having this issue, your barking up the wrong tree most likely.

lelizondo’s picture

Any possible solutions then?

Anonymous’s picture

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

Mackee’s picture

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

diego.pasc’s picture

I'm also having this problem since I installed DrupalChat with LongPolling enabled (as in comment #224)
Patch #61 seems to work.

yub_yub’s picture

subscribing

TuWebO’s picture

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

squinternata’s picture

i 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

hapydoyzer’s picture

Updated patch from comment #108 for Drupal 5.

Yurkos’s picture

same here - drupal 6.22, double login and double logout appearance...

crifi’s picture

chx’s picture

Status: Needs work » Closed (fixed)
grahamvalue’s picture

Status: Closed (fixed) » Needs work

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

geneatwell’s picture

Subscribe.

srees’s picture

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

mfuggle’s picture

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

awasson’s picture

Martin,

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:

name = Cache Clear (From matt@antinomia)
description = Clears browser cache on logout preventing false login issue 
package = Other
core = 6.x
files[] = cacheclear.module
version = "6.x-1.0"

cacheclear.module:

<?php
/**
* Implementation of hook_user()
*/

function cacheclear_user($op, &$edit, &$account, $category = NULL) {
  if ($op == 'logout') {
    cache_clear_all('*', 'cache_page', TRUE);
  }
}

Upload those to sites/all/modules (or wherever you have your contributed modules) and activate.

mfuggle’s picture

Very 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

Vako’s picture

Issue summary: View changes

Thank you awasson.
I had this issue for months and your solution worked perfect for me!

This code should be in Drupal core.

David Hernández’s picture

Version: 6.x-dev » 7.x-dev
Status: Needs work » Needs review

This issue still exists on D7. Here is a patch that should fix it, rerolled from the patch at #87

David Hernández’s picture

The last submitted patch, 87: login_linger_d7.patch, failed testing.

The last submitted patch, 95: jamesan_197786-95-D6.patch, failed testing.

The last submitted patch, 95: jamesan_197786-95-D5.patch, failed testing.

The last submitted patch, 105: jamesan_197786-105-D6.patch, failed testing.

The last submitted patch, 105: jamesan_197786-105-D5.patch, failed testing.

The last submitted patch, 108: include_etag_in_nonanonymous_response_D6.patch, failed testing.

The last submitted patch, 108: include_etag_in_nonanonymous_response_D5.patch, failed testing.

The last submitted patch, 234: include_etag_in_nonanonymous_response-D5.patch, failed testing.

David Hernández’s picture

Version: 7.x-dev » 8.0.x-dev
FileSize
1.93 KB

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

The last submitted patch, 246: 197786-245-d7.patch, failed testing.

Damien Tournoud’s picture

Status: Needs review » Postponed (maintainer needs more info)

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

David Hernández’s picture

Status: Postponed (maintainer needs more info) » Needs review

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

David Hernández’s picture

FileSize
2.81 KB

Updated D7 version, to fix the tests.

Status: Needs review » Needs work

The last submitted patch, 259: 197786-259-d7.patch, failed testing.

Damien Tournoud’s picture

Status: Needs work » Closed (cannot reproduce)

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

killes@www.drop.org’s picture

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

The last submitted patch, 105: jamesan_197786-105-D6.patch, failed testing.

izmeez’s picture

FileSize
2.71 KB

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

izmeez’s picture

FileSize
2.85 KB

This is a re-roll of patch in #259 against current 7.x git repo for drupal 7.40

Cyberflyer’s picture

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

izmeez’s picture

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