> Ryan Bloom wrote: > > > 1) If I have a page that I have served and it gets put in the cache, > > then it will be served out of the quick_handler phase. However, if I > > then add or modify a .htaccess file to deny access to that page, then my > > changes won't be honored until the page expires from the cache. > > True, and from any other cache along the chain between browser and server. > > > This is > > a security hole, because I don't know of anyway to invalidate cached > > pages. > > Sort of, leaning towards yes. I don't believe it's a hole as such > (because behaviour is consistent with any number of caches) however it > does violate the principle of least astonishment - when Apache's config > changes, Apache should be serving pages that correspond to that config > immediately, not later after cache expiry. > > > 2) If I have a page that uses access checking to ensure that only > > certain people can request the page, the cache_filter will put it in the > > quick handler. However, the page may not be allowed to people who will > > request it from the cache. I may be wrong about this one, but I see how > > the cache disallows pages that require authentication. I do not see how > > it can disallow caching of pages that require access_checking. > > Does the cache store pages protected by access control? If it does, the > cache should respond to Cache-Control: private headers set by the auth > modules (does Apache set these headers correctly?), OR - each user's > page could be considered a variant of the URL, which means the page gets > cached, but a version for each user, guaranteeing that user A does not > see pages from user B, ever. > > Hmmm... this could be a good thing for people who have password > protected websites that are expensive to generate. The cache could still > cache password protected stuff, but safely.
mod_cache does not currently cache password protected content, though it could be made to relatively easy by defining a handler for mod_cache and serving password protected content from the handler. This is a feature I intend to implement. > > > 3) It isn't possible for a module author to circumvent the > > quick_handler phase. If I write a module that doesn't want to allow the > > quick_handler phase, for security reasons, I can't enforce it. > > True. That is true of all the other hooks as well. It appears you are judging the quick_handler much more harshly that the other hooks which can just as easily be abused to the detriment of the server security. Use the hook correctly and there are no security exposures. I think we could easily modify the server to enable quick_handler to return one of three or four values DONE, DECLINED, OK or an HTTP error. Returning DONE would allow the server to ignore calling other module's quick_handlers (if there are any). > > > While I understand that we are giving people a lot of rope and asking > > them to use it wisely, this phase gives too much rope, and invites > > people to hang themselves. > > I think quick_handler should not be removed, but rather moved to before > the handler, but after the auth. I strongly disagree. The whole idea of the quick_handler is to bypass location_walk, directory_walk, access and auth checking. The overhead for all these steps adds up. I also have a prototype ESI fragment cache/assembler that relies on the quick handler being right where it is in the request cycle. Bill
