Authenticated users incorrectly served cached pages

The only thing that prevents authenticated users getting cached pages is the presence of a cookie (named DRUPAL_UID) set by Boost. This cookie is set when users login (after Boost has been activated).

Can you check whether you actually have the cookie set in your browser? Firefox should be able show this information, at least.

Hmm, I bet you had to re-login somewhere in that sequence, which would have set the cookie, after which everything would've worked as expected.

I think it is possible to explain what happened to you in terms of the fact that Boost only sets the DRUPAL_UID cookie when users login. After initially installing and activating Boost, you wouldn't get the cookie until you re-login, and hence the problems.

So this is probably a bug of sorts, actually. For 100% correct behavior after login, we'd probably need to set the cookie either on every page request by authenticated users (and clear it on logout, as is done already). It might also not be a bad idea to try and set the cookie for the administrator when he first installs the module.

Thoughts, anyone?

(Just to clarify: when I said "that sequence", I meant point 1 - the DRUPAL_UID cookie is only set on login, so it could not be got another way.)

I just came to post about this exact issue. After I installed I verified the cache works but then found my Admin user was being served the cached pages. Definitely needs to install the cookie when first activated on the administration page.

Also FYI, this module works fine on a Litespeed web server (it has apache compatible mod_rewrite).

http://drupal.org/node/253932
http://drupal.org/node/274129
http://drupal.org/node/194776

all duplicates.

I don't understand how the following code in the .htaccess can ever evaluate to false:

RewriteCond %{HTTP_COOKIE} !DRUPAL_UID

It translates as 'if the cookie named DRUPAL_UID hasn't been set'. How does the cookie ever get a chance to be set? This is the process as far as I can see:

1. User is anonymous. !DRUPAL_UID evaluates to true in .htaccess.
2. User fills in login form and presses submit, browser makes request.
3. .htaccess is the first to 'see' the request. As Drupal hasn't had a chance yet to process the users login details the value of !DRUPAL_UID is still true.
4. As the value of !DRUPAL_UID is true, .htaccess serves a cached page.
5. The cycle continues, !DRUPAL_UID is never set to true as Drupal functionality for setting a cookie comes after .htaccess.

I know my logic must be flawed, as Boost works for me if I login twice(surprisingly, refreshing the page after the first login doesn't work).

For some reason I can login from the homepage successfully the first time. Baffling.

I've just found out another possible cause of the problem!

If I add the following code before the BOOST specific code in .htaccess:

RewriteEngine on
RewriteRule ^(.*\.(html))$ reg.php?path=$1 [L]

and create a file called reg.php and in reg.php enter the following php code:

print_r($_SERVER);

I notice the following values when a user logs in (the bolded values are noteworthy):

DRUPAL_UID=1
[REDIRECT_QUERY_STRING] => path=files/cache/path-to-HTML-boost-file
[REDIRECT_REDIRECT_STATUS] => 200 [REDIRECT_STATUS] => 200
[REDIRECT_URL] => path-to-HTML-boostfile
[QUERY_STRING] => path=path-to-HTML-boost-file
[REQUEST_URI] => /the correct, non-html, path
[argv] => Array ( [0] => path=files/cache/www.mysite.com/0/path-to-HTML-boost-file )

So, it appears that $_SERVER[REQUEST_URL], $_SERVER[QUERY_STRING], $_SERVER[REDIRECT_QUERY_STRING] are being populated before the Boost .htaccess has time to do anything. Is this something to do with Drupals default login module or perhaps another module, such as login_destination? I'll check it out.

I don't have logindestination enabled, so I'm guessing that Drupal by default tries to redirect the user upon login to the page they were previously on.

phonydreams2 - did you see Arto's comments in #4 ?

Hmm, I bet you had to re-login somewhere in that sequence, which would have set the cookie, after which everything would've worked as expected.

I think it is possible to explain what happened to you in terms of the fact that Boost only sets the DRUPAL_UID cookie when users login. After initially installing and activating Boost, you wouldn't get the cookie until you re-login, and hence the problems.

On my site, I did TRUNCATE sessions; - so all my users had to log back in and had the cookie set - of course that's not an option for everyone.

I don't think my problem is the same as the OP, in retrospect. I hope I haven't confused this issue. In my instance Boost has been installed for several months now so Arto's comment in #3 doesn't apply.

I'm currently trying to figure out why certain values of the $_SERVER array, particularly [REDIRECT_URI] contains the URL to the cached boost file.

The normal Drupal behaviour is that when the user logs in they are redirected to the page they were on before they clicked the 'submit' of the login form. However, with Boost, the user is redirected to a cached html page when they login(because that's the page they were on before login).

At least that's my understanding of what's happening.

Okay, I feel embarrassed. This is what I had in my .htaccess file:

#RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
RewriteCond %{DOCUMENT_ROOT}/files/cache/www.mysite.com/0%{REQUEST_URI}.html -f

Notice that the first line is commented out...I thought it was redundant code! Doh!

In case this helps anyone else, I had a similar issue where logged-in users were seeing boosted pages, and I tracked it down to the DRUPAL_UID cookie not being set. Tracing it backwards, I found that the cookie was supposed to be set inside of boost_user(). boost_user() was being called, but wasn't making it past the if (!BOOST_ENABLED) return; line. And that's when I realized that while the Boost module was installed, and the htaccess rules added, I had turned off the static page cache option on the Performance page at some point. D'oh!

So from my experience so far, I recommend checking these things if you're getting cached pages while logged in:
1. Make sure static page cache is activated on the Performance page
2. Make sure that the page from which you're logging in (usually /user or /user/login or whatever, but could be any other page if you have a login block) is not getting Boosted -- you can either add it as an exception at /admin/settings/performance/boost or throw it in as additional RewriteConditions in your .htaccess.

Still allow for the cookie to be set/unset even if this module is disabled.

committed

Closing all 5.x issues; will only reevaluate if someone steps up #454652: Looking for a co-maintainer - 5.x

Reason is 6.x has 10x as many users as 5.x; also last 5.x dev was over a year ago. The 5.x issue queue needs to go.

Not sure why this is showing as 'active', sounds like a d.o upgrade bug. Re-closing issue.