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.

This is strange.

1. I did indeed have a cookie in my browser (firefox). I could access the admin pages, the edit pages of the cached nodes by knowing the url and all the other things that I would need adim privileges to do.
2. I deleted my cookie. Now access to priveleged pages was (luckily) not granted.
3. I logged in and now have full access to non-cached pages.

I do not have any explanation to what went wrong with the old cookie though.

The Issue is probably, somewhat, "closed", I guess?

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 see. Good to know that there might be an explanation. For my use it is no big of a deal. I don't have that many logged in users. And I guess that changing a larger site's cache method isn't done while it is online, so that shouldn't be too much of a problem either.

What happens when the site is in maintenance-mode? Does all users loose their sessions then? That could be a kind of solution: When the module is activated it checks to see how many logged in users there are. It then informs you of any consequences of turning the module on and gives you the possibility of deleting the sessions.

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.scoopkorea.com/0%{REQUEST_URI}.html -f

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