Supporting cached pages for authenticated users

Boost doesn't support caching for authenticated users, since it only has one cache: for anonymous users. It's more complicated than changing the .htaccess file--that change above would just serve logged-in users pages from the anonymous cache. If your logged-in users pages are exactly the same as your anonymous users pages, then you could try it, but then there wouldn't be much point of creating an account in the first place since one would receive the same content/functionality as an anonymous user.

Actually, Boost was originally designed to potentially also support authenticated user caching. Hence the user ID (hard-coded to '0' for the anonymous user) being included in the cache directory path all the way up until the 5.x-1.x-dev releases.

The problem is that actually implementing this functionality would have complex security implications, as deciding which user to serve a page to would be based on a user-supplied cookie; while this could perhaps be made secure through cryptographic hashing, it would be a lot of work to implement correctly and even more work to support non-expert users having issues with on an ongoing basis.

For this reason, and due to never having actually needed this myself, I've finally dropped the concept from the 6.x-1.x-dev branch. I'm not averse to reviewing patches for this in the future, but they would have to be very well thought out indeed.

@arto and others - perhaps another interesting enhancement is role based caching like block module now does in d6. here is the cache key function.

I don't really see how having individual caches for each logged in user could help improve performance. How often does a user reload the same exact page unless it's been updated?

Implementation of any type of caching using static files for authenticated users would be a daunting and complex task. Caching by role instead of having user-specific caches does seem like a better route. Ajax could be used for loading dynamic content if needed, especially pieces that require authentication. But I see this as being more than a patch... it seems more like a fork of the Boost module. I'm somewhat inclined to attempt this, as I'm developing sites that require many users to be logged-in. Does anyone have any other thoughts on this?

Look at the different cache strategies for blocks in D6. this is an analogous situation. it is true that per user is barely helpful. better to focus on per role and 'custom' (i.e. per group)

Jonah, if you're interested in attempting this, I say go for it but don't underestimate the complexity. The first thing to solve is how to secure the cookies that tell the .htaccess directives which role's content to serve; the cookies must be made unguessable and unforgeable, so some form of hashing is likely the answer.

Just an update... I've released a new module that allows pages to be cached for authenticated users:

http://drupal.org/project/authcache

Atro, I just wanted to say thanks, since I used a little bit of code & techniques from the Boost module.

This module might change things...
http://drupal.org/project/ajaxify_regions

Create a new dir to serve auth pages from, to make the rewrite rules easy (same as before, just no cookie check). Would rely on other modules like ajaxify_regions to handle the content difference between anonymous/authenticated. Have a separate check for what pages can be cached. Option to inherit from the anonymous setting (run it twice in short). Call this 6.x-2.x.

Just in case someone wants to do this without any official support, change this

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR https request
  RewriteCond %{REQUEST_METHOD} !^GET$ [OR]
  RewriteCond %{REQUEST_URI} (^(admin|cache|misc|modules|sites|system|themes|node/add))|(/(comment/reply|edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
  RewriteCond %{HTTPS} on
  RewriteRule .* - [S=7]

To this

  # Caching for all users
  # Skip boost IF not get request OR uri has wrong dir OR https request
  RewriteCond %{REQUEST_METHOD} !^GET$ [OR]
  RewriteCond %{REQUEST_URI} (^(admin|cache|misc|modules|sites|system|themes|node/add))|(/(comment/reply|edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTPS} on
  RewriteRule .* - [S=7]

2.0 Tag

Allow for each content type to be different. Enable authenticated caching of AJAX and XML but not HTML; ect... The cache would be generated by anonymous users, authenticated users would never be allowed to place an object in the cache.

Subscribe

+1 :)

You can do so as well with NGINX; if you use the rules from http://groups.drupal.org/node/26363, just comment out the three following lines:

        if ($http_cookie ~ "DRUPAL_UID") {
            return 405;
        }

subscribe

Can I use this module: http://drupal.org/project/ajaxify_regions with authcache?

subscribing

+1 subscribing

Subscribing.

Am I wrong if I say that if we enable the Turn off clean url's for logged in users option, we do not have the same cached page for authenticated an anonymous user. It is no big deal for to choose this option, as clean URLs is mostly for SEO purposes.

Well of course we should redirect anonymous users if they try to access directly the non-clean URL settings...and vice versa (more complicated).

Other issue : it seems that Boost is not triggered by authenticated users (which ruins the theory) but I presume it is not a big work to change that behaviour...

subscribing

I tried to remove this line in Boost dev version.

RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]

It seems to work but there was no any indication at the bottom of the page when view source saying Page cached by Boost...... This happen to both Anonymous and Authenticated user. Is this normal?

Also checked Boost Status block and it indicated that it was cached as it should. But then, when I used Authenticated user to load that page. The speed of Page execution time (Devel Module) didn't seem to improve. My question is how to check if the page I got for authentication user is really serve from Boost?

Thanks

I am really interested in this issue even though it has been open for a while and not much activity recently. I tried #11 but it didn't seem to work. Just to clarify, that code goes in .htaccess? It also seemed to have the effect of taking away cached pages from anonymous users, pages loaded more slowly and html comment in source code of page was no longer there.

To know that Boost served the page.
You should see the following in the response headers:
Date: Fri, 23 Sep 2011 23:29:03 GMT
Server: Apache
X-Drupal-Cache: HIT
Etag: "1316819009-1"
Link: ; rel="shortlink",; rel="canonical"
X-Generator: Drupal 7 (http://drupal.org)
Cache-Control: public, max-age=86400
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Last-Modified: Fri, 23 Sep 2011 23:03:29 GMT
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

200 OK

The key being this bit: X-Drupal-Cache: HIT

wolfrage, I just tested it on my site that boost enabled for just anonymous user. I saw "Page cached by Boost......" in the end of source page. However, when I looked at header response, I don't see "X-Drupal-Cache: HIT" as you said though. Below is what I got :

HTTP/1.1 200 OK
Date: Sat, 24 Sep 2011 03:46:27 GMT
Server: Apache
Last-Modified: Sat, 24 Sep 2011 03:27:35 GMT
Etag: "da18020-2132a-4ada781c297c0"
Accept-Ranges: bytes
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 18862
Keep-Alive: timeout=2, max=2048
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

I don't use boost anymore, but still wonder if 'X-Drupal-Cache' is only related to boost?
For my site I get:

X-Drupal-Cache	MISS
Cache-Control	no-cache, must-revalidate, post-check=0, pre-check=0

It looks like cache isn't working?
How can I make sure if my site caching works?