Re: [squid-users] Question about caching pages and signed in users

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
Received on Wed Feb 04 2009 - 06:45:37 MST