Kinder, gentler ignore-auth option

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Kinder, gentler ignore-auth option

Benno Blumenthal
Hello,

I tried the ignore-auth option in 2.6STABLE12 and found that it
destroyed authentication, i.e.  it behaves like

Cache-Control: public
Vary:

Not clear if that it what is intended or not.      Would it be possible
to have the behavior

Cache-Control: public
Vary: Authorization

either in ignore-auth  or  in some other option?   Then authorization
would still work, and it would cache for each user under Basic
authentication (not digest, unfortunately).

I also tried header_replace, but that only works if the header lines are
there, not if they are missing.  And even if I got the Header lines in
there, not clear that squid would pay attention to them without running
it through squid twice.

Benno


Benno
Reply | Threaded
Open this post in threaded view
|

Re: Kinder, gentler ignore-auth option

Henrik Nordström
mån 2007-05-21 klockan 10:43 -0400 skrev Benno Blumenthal:

> either in ignore-auth  or  in some other option?   Then authorization
> would still work, and it would cache for each user under Basic
> authentication (not digest, unfortunately).

Why do you want Squid to act as a per-user cache? The browser caches
does that job pretty good..

Regards
Henrik

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kinder, gentler ignore-auth option

Benno Blumenthal
Henrik Nordstrom wrote:

> mån 2007-05-21 klockan 10:43 -0400 skrev Benno Blumenthal:
>
>  
>> either in ignore-auth  or  in some other option?   Then authorization
>> would still work, and it would cache for each user under Basic
>> authentication (not digest, unfortunately).
>>    
>
> Why do you want Squid to act as a per-user cache? The browser caches
> does that job pretty good..
>
> Regards
> Henrik
>  
Because my client is not a browser, it is a service that analyzes data,
and uses other services to access data, and I wrote the server/client to
let squid do the caching, rather than reinventing the wheel.   I am
encouraging the data service in question to label their HTTP responses
correctly (with Cache-Control: public and Vary: Authorization) headers,
but not clear that they will pay any attention to me, a story you
probably have heard before.

I did actually figure out a way around the problem:  a data access
involves several HTTP requests (as it happens), so I wrote a pair of
refresh rules: one pattern for the first request of the set (so that it
won't cache and authentication happens), and I ignore-auth cache the
rest of the set (which is the important data payload -- read slower --
anyway).

But I wrote in part because I couldn't be sure which way ignore-auth was
intended:  it would be nice if the documentation were explicit about the
header equivalent.

Thanks for asking,

Benno


Reply | Threaded
Open this post in threaded view
|

Re: Kinder, gentler ignore-auth option

Henrik Nordström
mån 2007-05-21 klockan 17:39 -0400 skrev Benno Blumenthal:

> But I wrote in part because I couldn't be sure which way ignore-auth was
> intended:  it would be nice if the documentation were explicit about the
> header equivalent.

It's intended for public material on an authenticated server. I.e. where
the server should have responded with "Cache-Control: public" to allow
caching even if the request included authentication credentials.

Hmm.. you are right. The documentation in squid.conf.default is a bit
misleading on this. I'll fix it up.

                ignore-auth caches responses to requests with authorization,
                as if the originserver had sent ``Cache-control: public''
                in the response header. Doing this VIOLATES the HTTP standard.
                Enabling this feature could make you liable for problems which
                it causes.

Regards
Henrik

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kinder, gentler ignore-auth option

Henrik Nordström
In reply to this post by Benno Blumenthal
mån 2007-05-21 klockan 17:39 -0400 skrev Benno Blumenthal:

> Because my client is not a browser, it is a service that analyzes data,
> and uses other services to access data, and I wrote the server/client to
> let squid do the caching, rather than reinventing the wheel.   I am
> encouraging the data service in question to label their HTTP responses
> correctly (with Cache-Control: public and Vary: Authorization) headers,
> but not clear that they will pay any attention to me, a story you
> probably have heard before.

Ok. So requesting http://user:password@host/path without an
Authorization header and refresh_pattern ignore-auth will probably do
what you are looking for without the need for Vary magics..

This syntax is a Squid extension of the HTTP URI scheme but following
the general Internet URI syntax. Squid automatically translates the
user:password part into Basic HTTP authentication when forwarding the
request to a web server (but not when forwarding to another proxy).

This was implemented to allow url rewriter / redirector helpers to add
login details to rewritten requests, but works equally well when
received from the client.

As the login credentials is in the URL it automatically becomes part of
the cache key, avoiding the need for Vary.

Hmm.. most likely ignore-auth isn't needed either on such URIs as there
is no Authorization header.

Regards
Henrikm

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kinder, gentler ignore-auth option

Benno Blumenthal
In reply to this post by Henrik Nordström
Henrik Nordstrom wrote:

> mån 2007-05-21 klockan 17:39 -0400 skrev Benno Blumenthal:
>
>  
>> But I wrote in part because I couldn't be sure which way ignore-auth was
>> intended:  it would be nice if the documentation were explicit about the
>> header equivalent.
>>    
>
> It's intended for public material on an authenticated server. I.e. where
> the server should have responded with "Cache-Control: public" to allow
> caching even if the request included authentication credentials.
>
> Hmm.. you are right. The documentation in squid.conf.default is a bit
> misleading on this. I'll fix it up.
>
>                 ignore-auth caches responses to requests with authorization,
>                 as if the originserver had sent ``Cache-control: public''
>                 in the response header. Doing this VIOLATES the HTTP standard.
>                 Enabling this feature could make you liable for problems which
>                 it causes.
>
>  
Fixing the documentation is a fine solution, but I wanted to explain my
thinking before dropping the subject entirely.  First of all, my squid
is being accessed by multiple users.

The pair of header lines

Cache-Control: public
Vary: Authorization

as you pointed out, this allows caching on a per user basis, for Basic
Authentication and for Digest Authentication if the client does not
supply an cnounce.
(As it happens, I get data from some places with basic authentication,
and some data from places with a slightly modified digest authentication).
I do this not because I want the user stuff cached separately per se,
but because I want Authentication to work, i.e. I need the challenge
pages so that the source server can validate users.  If I do the following,

Cache-Control: public
Vary: none

Then the first user that gets a protected page will prevent the
challenge from being sent to all subsequent users, breaking
authentication for that page.  So no server that wants authentication to
work would ever set headers this way.  I can get around it in my case
because I know which request is made first in the set, so I can just
write my refresh_pattern to not cache that (i.e. no ignore auth) and
authentication works, the significant payload being in the subsequent
requests (which have an ignore-auth and cache).  As much as I hate to
admit it, your way actually works better for me, because the subsequent
requests are cached across users, which makes up for the one page type
not getting cached.  But it is a fussy configuration -- for most people
using ignore-auth will simply break authentication unless they really
know what they are doing.  Thus the extended documentation.

Meanwhile, the real solution is to get the data server to put the right
headers on -- I'll keep working on that.

Thanks,

Benno


Reply | Threaded
Open this post in threaded view
|

Re: Kinder, gentler ignore-auth option

Henrik Nordström
ons 2007-05-23 klockan 17:29 -0400 skrev Benno Blumenthal:

> Then the first user that gets a protected page will prevent the
> challenge from being sent to all subsequent users, breaking
> authentication for that page.

What specs says should be used in such cases, when caching is desired,
is

Cache-Control: max-age=0, must-revalidate

and since authentiation is also used

Cache-Control: max-age=0, must-revalidate, public


Should be possible to add refresh_pattern options for this I suppose,
but not sure if it will find many valid uses outside your setup. But if
you submit a patch it may be considered.

Regards
Henrik

signature.asc (316 bytes) Download Attachment