Posted by LPCA on November 9, 2010 at 1:15am
42 followers
| Project: | Authenticated User Page Caching (Authcache) |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | simg |
| Status: | active |
Issue Summary
hey
is a drupal 7 port likely?
cacherouter is being split into several modules
Comments
#1
Yep, a Drupal 7 port will happen.
#2
Thanks. Subscribing.
#3
When? Drupal 7 release tomorrow.
#4
Probably later this month.
#5
Ok. thx.
#6
For 7.x is there a good reason to have boost and authcache be different modules? We could combine them.
#7
Authcache and Boost are rather different modules... Authcache is on a different layer since it mainly just provides an Ajax interface and modifies HTML before placing into the cache bin (which could be anything, a database, memcached, APC, etc), while Boost provides a new caching engine for saving pages to disk.
#8
Boost could serve to authenticated users. Right now I see boost having 3 cache variants for a wide array of sites: normal, auth, mobile. Thinking about this, boost/authcache should remain as separate modules. So the question is what can I do to make auth storage more accessible for you. I haven't built it, but I could see it being useful.
#9
I'm searching for a cache solution to boost my small Drupal 7 site (blog, forum and pages).
Is it possible to speed up a Drupal website with authcache and use it with http://drupal.org/project/content_refresh to serve new contents immediate to the guests and members?
Subscribe
#10
still not see the D7 branch yet..
#11
subscribing
#12
subscribing
#13
subscribing
#14
subscribe
#15
subscribe
#16
subscribing
#17
Subscribing...
#18
Any update here?
#19
sub
#20
sub
#21
subscribing
#22
subscribing
#23
Is there something happening with this or has it been forgotten about? D7 is missing this kind of feature
#24
subscribe
#25
+1
#26
+1
#27
+1
#28
+1
#29
Please learn to login and press follow, instead of filling entire pages with "subscribe" and "+1".
#30
Hi All,
Just thought I would alert you to the fact that I have started work on a D7 port of this module.
Current status is that the module installs OK, most of the UI works (adding "rules" doesn't yet work) and I've fixed most of the issues reported by the coder module (and some other D7 compatibility issues).
I *think* authcache D7 is currently writing pages to the cache (I'm using memcached) but unfortunately not reading from the cache when generating pages. Caching seems to have changed significantly from D6 -> D7 so I need to port includes/authcache.inc to the D7 approach.
Plenty of work still to do, but I *need* this module to work so I'm going to be focused on making this happen over the next few days / weeks.
I've attached my code so far. Don't expect it to solve any performance problems but you're welcome to have a play with it. Any insight experienced authcache users / developers are able to offer will no doubt be useful (and certainly appreciated !)
#31
just an update.
made excellent progress yesterday. have authenticated pages being served from cache and page generation times down from about 950ms to 5ms on my dev system :).
one minor (but significant) problem remains, and that is the data being written to the cache is blank :/
The problem is the following code in authcache.helpers.inc -> function _authcache_shutdown_save_page().
// Get buffered HTML$buffer = ob_get_contents();
ob_get_contents() returns empty and therefore an empty $buffer is currently being written to cache.
I will no doubt get to the bottom of this, but any input / suggestions / feedback welcome.
Latest code attached.
#32
Ok, this one is pretty damn close. The javascript personalisation bit isn't yet working and you need to make a small core hack to make it work (to get around the ob_get_contents problem described above) though I hope to work out a way to remove that requirement.
I'm currently getting approximately 750 authenticated requests a second from my development machine (quad core desktop running Apache with 8GB ram) (ie average of 1.3 milliseconds per request!)
#33
There was some error during the plugin enabling process on line 23:
authcache_user_login('login', $user, $user);And after enabling the plugin in settings.php there were two errors in admin/config/development/performance/authcache
So I couldn't get it working and when I tried to access the website itself there was just an ampty page with Array.
Just a feedback :)
Please continue your work, very many people are waiting for this module on D7, you would be a hero for us all.
#34
>There was some error during the plugin enabling process on line 23:
the exact error would be very useful :)
Also worth running clear cache and logging out / in
#35
Could you consider creating a sandbox project on d.o or on github or similar to track the changes you're making and also make it easier for users to pull the latest changes (rather than have to download and unpack/overwrite tarball contents) ?
Thanks for working on this!!
#36
Error during the enabling process:
Fatal error: Only variables can be passed by reference in /htdocs/sites/all/modules/authcache/authcache.install on line 23
on admin/modules/list/confirm
#37
@mig5 Sandbox project created http://drupal.org/sandbox/simg/1419168
@anybodywise: latest code (now in sandbox) should fix the error on #36. alternatively simply change line 23 of authcache.install from
authcache_user_login('login', $user, $user);to
authcache_user_login($user, $user);#38
Notice: Undefined index: authcache_is_db in require_once() (line 112 of /htdocs/sites/all/modules/authcache/authcache.inc).Notice: Undefined index: authcache_handler in require_once() (line 118 of /htdocs/sites/all/modules/authcache/authcache.inc).
while having the latest memcache (7.x-1.0) and this in settings.php:
$conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';$conf['cache_backends'][] = 'sites/all/modules/authcache/authcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['memcache_key_prefix'] = 'myprefix';
#39
But it really works. I have a very highly loaded page with a lot of bocks, modules and stuff, and it loads quite slow for auth users, enabling this module made the page load as fast as if it was anonymous user.
I can't wait to enable it for production.
#40
fixed issues in #38. also fixed the javascript error.
in *theory* the module now "works" :)
one issue that has become apparent in porting the module is that there is currently a "security consideration". Authcache potentially makes all cached content available to anyone who has the appropriate cache_key cookie set. This makes it somewhat easy for a "curious" person to fake the appropriate cookie value and gain access to "private" content from the cache.
This means that authcache is currently only suitable if you want to speed up sites with roles used for "personalising" the content. Authcache currently only provides very "casual" protection to private information so if you want to keep certain content totally protected you will need to wait for a subsequent release of this module.
There is a solution to this problem which requires further work and most likely a small performance penalty. Will keep you informed.
#41
latest version doesn't need memcache - though it's still a configurable option
I've created a new FileCache.inc which stores cache data in the local files folder.
As I suspected, FileCache is significantly faster than MemCache.
I'm now getting 2.54ms per request with FileCache compared to 5.4ms with MemCache.
FileCache also handling ~1400 authenticated requests per second.
Best of all, it's simple to set up and you can run it on *shared hosting* :)
Check out the README.txt - hopefully good instructions
#42
can I use this in conjunction with the memcache and file cache modules in Drupal 7.
#43
@SocialNicheGuru - yes. all explained in the README.txt
(wish I'd known about the FileCache module, that might have saved me a days work yesterday :/ )
#44
Update: Now that I know about the FileCache module, I would recommend people go with that (run your own benchmarks though). The FileCache.inc that I've included with Authcache isn't complete (can't clear cache for example) and I don't see any point in maintaining / fixing it if there is already an existing FileCache module.
#45
I posted some comparative performance benchmarks if you're interested:
http://groups.drupal.org/node/206138
#46
Thanks for sharing the results simg. Looking good so far.
#47
I suggest we can open a D7 branch and release the development version now, then more users can find and test it, especially users not using git.
#48
>I suggest we can open a D7 branch
I'm not the maintainer for this module so I can't do this. I've contacted the maintainer (Jonah Ellison) but not heard anything back yet.
I'm going to try and get the module onto a production site this week which will give me a bit more confidence that's there's nothing major that I've forgotten.
(The "security consideration" in #40 would be nice to solve)
#49
Hi Simon, thanks for the great work on the D7 port and apologies for the late reply. I've made you co-maintainer so you can put it up and people can start creating separate issues (I also sent you an email with a few questions/notes).
Security issues shouldn't be a concern since each cached page needs to be exactly the same for each user within a role. Personalized content should never be cached on the page level (admins can exclude URLs). The Ajax phase can also be used to retrieve any sensitive content, since it validates against the session. Finally, users only have access to the cache key when they log-in. (Anonymous users cannot guess the key for different roles.)
#50
Hi Jonah, thanks for the email :)
The "security consideration" is as follows (not sure if this applies to D6 version, but this is how D7 version currently works):
1. Authenticated user requests a page with cache key of say "e38ce7" which corresponds to groups "admin" and "sales".
2. Drupal bootstrap calls Authcache which gets a cache hit and delivers the page from the cache.
At this point, the user has not actually been authenticated to check they are who they say they are.
This means that anyone who could work out that creating a cookie with an authcache_key of e38ce7 will have view access to all content on the site viewable to the "admin" and "sales" groups.
This may (or may not) be tolerable in order to get fast response times.
What also needs to happen (I think as an optional extra) is for session data to be loaded (from a fast cache) to check the users session is valid. This will obviously incur some kind of additional overhead.
#51
But the user needs to aquire the cache key first, and the only way to do this is if they can log-in as a user that has an "admin" and "sales" role, or steal the user's cookie (if someone can do that, then there are much bigger problems).
Validating the session for each page requires connecting to the database and performing queries, so there is a performance hit. But if you want to include an option to do this, that's fine.
#52
>or steal the user's cookie (if someone can do that, then there are much bigger problems).
all it needs is for a knowledgeable person to take a very quick look at someones (ie their boss?) browser settings (ie cookies), get the cache key (easy to remember) and add that to their own browser (or other information retrieval software). trivially easy to do and this gives the "curious" person access to view all the information belonging to the groups of "the boss". A very real security consideration for some types of website.
edit: this may be a bad example since the same curious person could simply steal their bosses session cookie (if they had a bit more time and pencil / paper). still can't help feeling that a "site/group wide" unchanging authentication cookie (which is what the authcache_key basically is) would be a security issue for many sites.
>Validating the session for each page requires connecting to the database and performing queries, so there is a performance hit.
My suggestion is to store session state in a fast cache like FileCache or Memcache*. That way there will be no need to connect to the database. There will of course still be a performance hit but it won't be anything like as bad as hitting the database. There should be an option to enable or disable "session validation" so that users can trade reduced security (if they don't need it) for increased speed.
*Apparently work is afoot elsewhere to enable this (I don't currently know why it requires additional development to enable this)
#53
Yes, what I meant is that if someone wants to steal cookies, they would target the Drupal session cookie, which would give them full access to someone's account. This type of security concern is beyond the scope of this module.
If a site has private content, admins should just not cache the pages or roles. Caching pages works best when hundreds of users have access to the exact same content.
Sessions can be stored in cached, though the dilemma is that cache is meant to be temporary, while sessions are not (e.g. if cache is lost, it needs to be rebuilt/regenerated easily), so some type of database fallback is usually needed. This is a good read: http://dormando.livejournal.com/495593.html
#54
hi all, you might notice there is now a 7.x-1.x-dev release available.
it's early days. it meets my needs (and I'll be putting it on a production site very soon) but it requires testing and I would *expect* you to find errors and functionality that I haven't ported across properly (I haven't tested the javascript functionality at all for example).
report problems. you should get a pretty quick fix :)
#55
@simg Thanks for porting this module!
I'd like to give this module a try. Alas, I can't, because the documentation is so bad. Usually I just read the code, but even the code is extremely bad: lots of commented out logic makes it very confusing, and makes the entire module seem like one massive hack.
So … the instructions say I should add the following lines to my settings.php file:
$conf['cache_backends'][] = 'sites/all/modules/filecache/filecache.inc';$conf['cache_backends'][] = 'sites/all/modules/authcache/authcache.inc';
$conf['cache_class_cache_page'] = 'DrupalFileCache';
But that doesn't stop it from complaining about a missing
cache_incconfiguration. Should I add that too? Or is it a leftover from D6? Why is it not documented?Don't get me wrong, I do appreciate the time you've put into this, but right now, it's near impossible to figure out what works properly and what is a hack, and consequently: how one can configure this module to work reliably. If you can help me get started, I'll be able to contribute back, but until then, I won't be able to even try this module properly…
#56
@Wim
latest code now has "debug" comments removed so you should find it easier to read.
you also should find the "missing cache_inc" message is now fixed. (pretty sure this check is no longer needed in D7 but not entirely sure)
if you have any specific feedback about the documentation rather than "it's bad" that would be appreciated :)