Amos Jeffries wrote:
Tom Williams wrote:
I've been racking my brain trying to figure this out so I'm asking
the community here. I'm using Squid 3.0-STABLE12 as a reverse proxy
on Linux.
Here's the scenario:
An anonymous user visits my site, http://www.mysite.com/ and can
browse around just fine. As they browse around, Squid caches the
pages which are generated by a PHP-based web app. We're using these
Cache-Control headers to control the content caching:
Cache-Control: public, must-revalidate, max-age=0, s-maxage=10800
Ok, on all the pages there is a "sign-in" link they can click to sign
in to the site. When they click the "sign-in" link to sign in, we
switch to HTTPS to make sure the userid/password are sent securely.
Once they are signed in, they are returned back to the regular site
using HTTP but we set a cookie to signal the user is signed in. At
this point, we DO NOT want to cache the pages since the user is
signed in. This is where the issue arises.
After signing in to the site, the user gets the *cached* version of
the page they were on instead of the page which reflects they are now
signed in to the site. After the user signs in to the site, we send
this Cache-Control header to prevent caching of the pages after the
user is signed in:
Cache-Control: private, must-revalidate, no-cache, no-store,
max-age=0, s-maxage=0
The goal we are after is to have Squid cache pages for anonymous
users ONLY and NOT cache pages for signed in users.
Is this possible? If so, what am I missing to accomplish this?
The config you have above can be expected to do that. Have you noticed
otherwise?
Yes, we have. When the user signs in, they get redirected to the page
on which they clicked the "sign-in" link and get served the *cached*
page, which doesn't reflect their signed in status instead of the new
page that does reflect their signed in status.
So, if a user goes to http://www.mysite.com/page and clicks the
"sign-in" link on that page, they get taken to
https://www.mysite.com/sign-in-page, where they enter their
id/password. When they click the "submit" button to send that info,
they get redirected to http://www.mysite.com/page (using a HTTP
"Location" header) and instead of getting a fresh, non-cached copy of
www.mysite.com/page they get the cached version that was sent to them
before they signed in. If they click the refresh button in their
browser, the new page (which reflects the signed in status) is sent and
all is well.
Many alternate ways discussed very recently.
* Using Vary: header to tell Squid the Cookie: header determines the
result
* Using custom headers + Vary: to do same
Ah, I'll search the archives for this discussion. Thanks!
* Using HTTPS for the whole logged in session
* Using digest authentication that can be sent securely in headers.
* Using Cache-Control: private on secure pages.
* Using a secondary domain for logged in users
* Using URL tokens to split the private pages apart
Amos
Peace...
Tom
