Rune Langseid wrote:
Thanks for the reply Amos.
Just to clarify my intentions about this setup.
I my current setup all requests is sent to and handled by the CMS's
"index.php".
Since over 90% of the requests is anonymous users which always get the
same output I want accelerate this part. All authentication is handled
by the CMS, and is not something Squid needs to think about.
Okay. In that case you should not worry about bypassing squid for the
authenticated users.
All you need is to ensure that secure content for authenticated users is
at different URI than for anonymous. And that all pages have
Cache-Control: headers set to expire the page when you want it to.
If you go the route of using a query-string parameter to differentiate,
you will need to remove the recommended default non-caching of '?' URI
from squid.conf.
Or to keep using the cookie you should just need to set the
Cache-Control: and Vary: headers (Vary: Cookie)
The new polished www.squid-cache.org site does this in a way with its
*.dyn pages. Everything gets mapped and assembled by a control script
before display.
Amos
Amos Jeffries wrote:
Rune Langseid wrote:
Hi there,
I'm trying to set up a reverse-proxy in front of an CMS.
Ok.
Since there are both anonymous users, and logged in users accessing this
system I only want to serve squid-cache to the anonymous users.
WHY? Surey yoru authenticated users are allowed to do the same things
as anonymous (plus some extras only for them)
I was thinking of setting a cookie called "Authenticated" when the user
logs in as this is easy to check with "acl"
Like this:
acl cookie_is_set req_header Cookie ^.*Authenticated.*
However, I am facing a few problems then trying to let these user
through Squid.
I have tried this:
acl cookie_is_set req_header Cookie ^.*Authenticated.*
cache deny cookie_is_set
This setup works in a way, but Squid also deletes the cache-object used
by the anonymous users which is something I don't want. Could this be
a bug?
Sort-of. Squid does not fully support HTTP/1.1 - this type of URL
differences are part of the HTTP/1.1 support.
If its still occuring when squid is apparently HTTP/1.1 compliant then
it will be a bug.
I have also been experimenting with "always_direct" with no luck.
Like this:
always_direct allow cookie_is_set
I guess I am missing something important here...
always_direct bypasses the peer config you have for matching requests.
Is there another way to solve this?
Eg by using cache_peer and cache_peer_access?
Possibly. If you wanted one or other type of user not to be able to
request new content from the peer.
What I suspect is that you actually want to use:
miss_access deny !cookie_is_set
That way authenticated users are allowed to pull new objects int the
cache. and non-authenticated are only allowed to use those already
pulled in by somebody else.
Your CMS should be setting Expires: and Cache-Control: headers
properly to control which items are storable in the cache and which
need to be refreshed.
You purposed this setting;
miss_access deny !cookie_is_set
This will stop requests which is not authenticated (cookie does not
exist) which is something I don't want.
Anonymous users should generate cache if does not exists, or if it is
expired.
If the cookie exists Squid should just pass the request along to
index.php as if the cache did not exist.
The "cache deny cookie_is_set" does this, but it also releases the cache
for the page used by anonymous user.
I guess I'll end up modifying this function not to case a "RELEASE" on
the cache by patching Squid. This is not an ideal solution, but if it
works for now it is enough.
I'm using Squid 2.6.5, and my squid.conf looks like this:
--
cache_peer localhost parent 80 0 originserver
http_port 8080 vhost
acl cookie_is_set req_header Cookie ^.*Authenticated.*
cache deny cookie_is_set
#always_direct allow cookie_is_set
acl all src 0.0.0.0/0.0.0.0
http_access allow all
So by that config I read that you want ANYBODY to be able to access
any website through your proxy at port 8080?
I'd use:
- cache_peer_domain or cache_peer_access to limit the possible
destinations to those your peer provides.
- never_direct to prevent requests the CMS is not meant to provide
Also cookie's can be forged or spoofed easily. If you can try to setup
some proper authentication. The auth_param programs can be an easily
hand-coded script to test USER/PASS against anything you want.
That also allows the users use their familiar browser login controls
for your site.
The ports in this example of squid.conf was easy to misunderstand I guess.
When everything is settled Squid will of course run on port 80, and
Apache will be on port 8080 (just to pick one).
Regards,
Rune
