Re: 407/403 responses

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Thursday, July 12, 2001 10:36 PM
Subject: Re: 407/403 responses

> Robert Collins wrote:
>
> > So the question for the core team is:
> > Should I get the authentication code duplicating the 2.4 behaviour -
> > http_access deny line that fires on an authorisation failure (as opposed
to
> > authentication failure) will generate a challenge from each and every
> > challenge?
>
> As outlined before.
>
> http_access allow/deny non_matching_proxy_auth_acl -> ignored
> http_access deny proxy_auth_acl -> 407(401)
> http_access deny other_acl -> 403
>
> Not yet fully logged in, touching a proxy_auth ACL -> 407(401)

Yes. In other words, put backthe 2.4 behaviour. Ok, will do.

> ACL processing:
>
> User not matched by the proxy_auth ACL -> false (0).
>
>
>
> Question: How to generate scheme challenges in the first case where the
> user is authenticated but not authorized.
>
> Answer: authenticateFixHeader needs to be aware that the header fixup is
> due to authorization failure, not authentication failure, and then force
> the client to send new credentials even if the current ones are valid.
> This is the call to authenticateFixHeader from errorpage.c where the
> last argument is 1 (currently named "internal", should probably be
> "unautorized" or something similar...).

Answer #2: use abstracted "authenticateUserAuthenticated" in the fixheader
call.

Rob

>
> --
> Henrik
>