Hosting Issue - Missing mod_headers: logged out user sees auth pages stored in browser cache if previously authenticated

yes, I've noticed the same problem here.
pressing shift+refresh will force a fresh page load but it's not a good solution for alot of non-technical users.
Oddly, this still happens with mod_expires on and html set to expire in 1sec in the apache config.
Interested in a solution.

OK, I take it your solution about the setting the cache-control header to 'no-store' was the solution as that's what I found in the end.

This thread helped:

http://drupal.org/node/185075

It may also be neccessary to add the 'no-store' directive to your default .htaccess file also.
Either that or change it in bootstrap.inc around line 533, though that is a core hack which should be avoided if at all possible.

P.S Totally awesome module, by the way :-)

I have similar problem but unrelated to Boost module,
I have not been able to consistently reproduce it
but it seems to be related to the browser's cache

Checking out this solution

Hello,

I am experiencing this same issue on Firefox 3 with the 6.x-dev version of Boost.

Some testing reveals this:

After logging in and going back to my site's home page, Firebug shows that Cache-Control is set to "store" and not "no-store." So, when I hit the logout button, I am shown a browser-cached version of the home page as if I were logged in. I am using the bootstrap.inc core hack to work around this in the meantime.

Cache-control is set to "no-store" when visiting the site as an anonymous user. It's only when logged in that Cache-Control gets set to "store."

It appears this issue is in direct conflict with this one: #185075: Only apply "do not cache" headers to files inside the the cache folder..

@bbilocura
would you mind testing the Turn off clean url's for logged in users setting to see if that "fixes" the problem.

dup found #554982: Watchdog Logging Access Denied as Anonymous for Admin Actions

subscribe

Mikeytown2,

Unfortunately, disabling clean URLs for logged in users does not fix the problem. Firefox is still showing the logged in page after I log out unless I force-refresh in the browser.

I should add that Boost works as expected out of the box with IE and Opera. I'm only having issues with Firefox.

A related issue is at http://drupal.org/node/197786

This issue has been around for a while. It is not unique to the Boost module. I am getting ready to test the latest patch in comment #108.

I had previously applied the patch from comment #61, which is the same change as suggested by the OP and in comment #1 here.

I'm guessing that adding this to the .htaccess file won't work then? Can someone verify?
http://www.askapache.com/htaccess/using-http-headers-with-htaccess.html#...

<IfModule mod_headers.c>
  Header unset ETag
  Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
  Header set Pragma "no-cache"
  Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
</IfModule>

If you don't want to hassle with patching core, pressflow fixes this bug.
http://pressflow.org/

Can I get someone to confirm that switching to pressflow fixes the issue?

I need more info, to see if #11 or #12 works. I can then start to work on a fix/recommendation.

Using the patch of #10 (comment #61) and the OP gives me Access Denied when I use the back button.

I have not tried the .htaccess patch of #11.

I installed Pressflow described in #12. I navigated some authenticated user pages only and then logged out. Using the FF back button, I could see the previously viewed pages just as if I were still logged in. I added no-store, to the Cache-Control variable as noted by OP and in #10, and when I use the back button I get Access Denied, which is what I would expect.

PS: I like Pressflow. My first impression is that my shared hosting test setup seems slightly faster, but I have not measured it. Thanks for the tip.

@tally
so pressflow does not fix the issue correct?

The last thing to do before patching core would be #11. Can someone verify if this works?

had this happen Aug 30th (once) on davebeall.com(test site) with FF, almost tried #11, but can't reproduce it now.. will keep trying to reproduce. It was showing 1 cached page with View, Edit, Outline and Track tabs(was on that page, then logged out using admin_menu). Dumped the cached page with FTP manually.
I am almost sure it was Aug29th-dev, have since upgraded newer -dev.

updating title based on #197786: Some servers / browsers will cache pages even when header Cache-control: no-cache is set being marked as won't fix.

would someone who is experiencing this problem try this patch out: http://drupal.org/node/585424#comment-2073406. There's a slight chance it might fix it.

I'm experiencing this problem using the latest dev, which appears to have the fix from http://drupal.org/node/585424#comment-2077370 commited.

Sometimes, for me anyway, this also makes the logout function sometimes not work entirely, rendering the authorized user cache page on the logout redirect. Is it possible writing authorized cookies again somewhere in the loop of things?

This might be related info. Apache sets Etags for files, which means the paths that come from boost get an etag.
#608102: Option to disable etags for static boosted files

Firefox has been doing this to me using Boost 6.x-1.12. It's the browser cache.
I figured it was a firefox problem with 3.5.3
The logout hasn't been an issue, I am using admin_menu.
The admin_menu top bar goes away at logout, but the Drupal edit, view tabs remain until I clear the browser cache and history...
actually, I like the old version of firefox better.

Try disableing etags, let me know if that fixes it.

Header unset ETag
FileETag None

Add this to the bottom of your htaccess file.

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

try just this

FileETag None

Fixed..
login, edit a node(blog post) , save, logout, go back to blog node, tabs gone...

back track to double check, remove etag none; tabs are back..

Cool, thanks for the testing!

Hello,

#25 appears to solve the problem for me.

I'll make this the default, with the option to have etags on if desired.

we need to tell people what etags are and why they might want them on.

ie: use caution, etags can crash your server and burn your house down if used improperly!

By default no etags are given for php responses, only static files. So disabling it makes Boost even more transparent, but then the server will not return a "304 Not Modified" ever, so the site will seem slightly slower. It's a trade off, thus it should be a setting.

Would one of you mind testing the location of the etag? Place it below the </IfModule> tag.

  <FilesMatch "(\.html|\.html\.gz)$">
    <IfModule mod_headers.c>
      Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
      Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
    </IfModule>
    FileETag None
  </FilesMatch>

I tried it,, sorry, you just can't be right every time. But most of the time is perfectly fine..

lol. no it didn't work, acts as it did without it.

### BOOST START ###
  AddDefaultCharset utf-8
  <FilesMatch "(\.html|\.html\.gz)$">
    <IfModule mod_headers.c>
      Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
      Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
    </IfModule>
    FileETag None
  </FilesMatch>
  <IfModule mod_mime.c>

Just to make sure placement in the htaccess file isn't critical can you try this

### BOOST START ###
  AddDefaultCharset utf-8
  FileETag None
  <FilesMatch "(\.html|\.html\.gz)$">
    <IfModule mod_headers.c>
      Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
      Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
    </IfModule>
  </FilesMatch>
  <IfModule mod_mime.c>

nope, acts as before adding it

ok, lets try it after all the rewrite rules...

  FileETag None
  ### BOOST END ###

something not right here....
That don't work either..
I checked the file after upload to be sure it went with the change.. it's there.
but it's not working... Tabs are there after an edit.

Could the server be holding an old htaccess file somehow, like a cache..

put it at the end of the htaccess file. Apache may not like that inside the <IfModule mod_rewrite.c>...</IfModule> tags

i put it back at the end of htaccess and it still won't work..
but it was there before and it worked..

the internet has been acting weird the past half hour.. but that is probably a hop someplace

no rush, let me know the results of the various placements when your server is reading the htaccess file correctly. We know it works at the end of the file.

I was a bit premature in saying the ETags fix worked--now it stopped working for me too!

I'm confused, since I used the same steps to test the fix as I did now. Everything was working as expected last night, but not anymore.

FWIW, I tried placing the ETag line at the end of the file and after BOOST END. Neither works anymore. Very confusing.

I think I figured part of this out. If this is effecting you mod_headers is not installed with your version of apache.

Can someone who is encountering this issue give me full headers, using firebug? Headers for each step that you do when testing for this bug. Example

Response Headers
Date	Mon, 19 Oct 2009 18:44:54 GMT
Server	Apache
Expires	Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control	no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Keep-Alive	timeout=15, max=98
Connection	Keep-Alive
Transfer-Encoding	chunked
Content-Type	text/html; charset=utf-8
Content-Encoding	gzip

Request Headers
Host	www.example.com
User-Agent	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
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

Or google chrome can do it as well

Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Mon, 19 Oct 2009 18:48:43 GMT
Expires:Sun, 19 Nov 1978 05:00:00 GMT
Keep-Alive:timeout=15, max=100
Server:Apache
Transfer-Encoding:chunked

Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0

the top bar of the admin menu is not going away now.. have not tested etag placement yet today.

anonymous view front page

Date	Mon, 19 Oct 2009 21:13:55 GMT
Server	Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
Last-Modified	Thu, 15 Oct 2009 10:30:41 GMT
Accept-Ranges	bytes
Content-Length	7507
Cache-Control	max-age=1
Expires	Mon, 19 Oct 2009 21:13:56 GMT
Content-Type	text/html; charset=utf-8
Content-Encoding	gzip
X-lori-time-2	1255986673266

admin view edit node

Date	Mon, 19 Oct 2009 21:20:51 GMT
Server	Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By	PHP/5.2.11
Expires	Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control	store, no-cache, must-revalidate, post-check=0, pre-check=0
Set-Cookie	SESSf4f15e15b4e27b1361e21a7d370d3970=89bcf091e3bec8cd8f625a1a4329dea0; expires=Thu, 12-Nov-2009 00:54:11 GMT; path=/; domain=.davebeall.com
Last-Modified	Mon, 19 Oct 2009 21:20:51 GMT
Vary	Accept-Encoding
Content-Encoding	gzip
Content-Length	4080
Keep-Alive	timeout=5, max=98
Connection	Keep-Alive
Content-Type	text/html; charset=utf-8
X-lori-time-2	1255987088967

admin view node after save

Date	Mon, 19 Oct 2009 21:22:09 GMT
Server	Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By	PHP/5.2.11
Expires	Mon, 19 Oct 2009 21:22:10 GMT
Cache-Control	max-age=1
Vary	Cookie,Accept-Encoding
Last-Modified	Mon, 19 Oct 2009 21:21:55 GMT
Content-Encoding	gzip
Content-Length	8908
Content-Type	text/html; charset=utf-8
X-lori-time-2	1255987166976

anonymous view node after logout

Date	Mon, 19 Oct 2009 21:23:39 GMT
Server	Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By	PHP/5.2.11
Expires	Mon, 19 Oct 2009 21:23:40 GMT
Cache-Control	max-age=1
Vary	Cookie,Accept-Encoding
Last-Modified	Mon, 19 Oct 2009 21:21:55 GMT
Content-Encoding	gzip
Content-Length	8908
Content-Type	text/html; charset=utf-8
X-lori-time-2	1255987257277

note, just catching up today.. the etag is still on server

### BOOST END ###

  # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>
FileETag None

# $Id: .htaccess,v 1.90.2.3 2008/12/10 20:04:08 goba Exp $

EDIT I may not be a lot help with firebug.. I still haven't figured out all that stuff.

This issue is something that I can not programmatically fix. The no cache headers are not being sent out due to mod_headers not being installed with your version of apache.

Compare my site - anonymous view front page

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

To your site - anonymous view front page

Cache-Control max-age=1

One last thing to try: Setting the etag!

FileETag MTime Size

Give me anonymous view front page headers before and after, with the etag set.

anon front page

Date	Mon, 19 Oct 2009 23:32:25 GMT
Server	Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
Last-Modified	Thu, 15 Oct 2009 10:30:41 GMT
Accept-Ranges	bytes
Content-Length	7507
Cache-Control	max-age=1
Expires	Mon, 19 Oct 2009 23:32:26 GMT
Content-Type	text/html; charset=utf-8
Content-Encoding	gzip
X-lori-time-2	1255994982940

logged out front page after edit a node

Date	Mon, 19 Oct 2009 23:35:46 GMT
Server	Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By	PHP/5.2.11
Expires	Mon, 19 Oct 2009 23:35:47 GMT
Cache-Control	max-age=1
Vary	Cookie,Accept-Encoding
Last-Modified	Mon, 19 Oct 2009 23:34:32 GMT
Content-Encoding	gzip
Content-Length	7869
Content-Type	text/html; charset=utf-8
X-lori-time-2	1255995184134

And it probably didn't fix the bug either, did it... going to mark this by design. I would contact your host and ask about getting mod_headers included in apache; could be as easy as sudo a2enmod headers
http://man.he.net/man8/a2enmod

not a problem, submitted a note to the server guys.. it's their call, I made a decent case for it.
after all, it is a Drupal centric outfit.

I am sorry this cost you time.. I was going to let it go by..
I do not like wasting peoples time.

The best I can do is say Thank You

Thanks for posting the solution to this. I had exactly the same problem and it was driving me nuts as different browsers seem to behave differently in the way they cache content.

#25 and #47 solved this conclusively.

Also - for the benefit for others wading through this - I think it's worth clarifying that there are 2 separate - but related - issues being discussed in this thread.

1. A core problem with Drupal caching which has a workaround in #1
2. A problem with Boost and browser caching fixed with #25 and #47

In my case - because I'm running a social networking type site with content access restrictions - I needed to apply both fixes, but other situations may require only one, or neither.