On 22.05.2012 04:54, maxime.dumez wrote:
Hello,
I'm having issues with the authentification. A request come from an
other proxy
and squid manage the authentification over a databases and the
caching.
The fake basic authentification and the databases authentification
helper work
properly but I need to limit the retry to 3 and drop a forbidden in
the following
case.
Lets see if I'm understanding you correctly...
a) You want to reject the client request if they send incorrect
credentials 3 times in a row?
==> Squid does not support this on its proxy-auth validation at
present. A client may open unlimited parallel connections and pipeline
multiple requests on each before the first response is received back.
Also, proxies *do* multiplex/interleave requests from multiple clients
into one persistent TCP connection. Patches welcome though.
NP: I'm thinking the best way is support for a key=value parameter
back from the helper which indicates what status code to send on the
proxy-auth response on rejects. That way the limit is completely
controlled by the helper with no guessing or mistakes by Squid.
b) You want Squid to limit its retries to 3 attempts before generating
a failure response to the client?
http://www.squid-cache.org/Doc/config/forward_max_tries/
It will not be a 403 forbidden message generated by Squid. It will be
400 gateway unavailable or somesuch. Since the *client* login did not
fail, the gateway (squid) has broken connectivity.
NP: if the request gets through to the origin and gets a response
Squid does not re-try.
c) you want squid to throttle the client to 3 requests which get
401/407 responses, and convert the status on any others to 403?
==> this is not possible in HTTP. Each request is independent of
every other request (see [a] for why). Some auth schemes also *requires*
multiple 401/407 responses to happen before being allowed. NTLM comes to
mind easily with its 3-request handshake, but Basic auth can piggy-back
almost anything. There is simply no way to know at Squid what the client
is doing with the origin or even the local auth helper.
In the current configurations (see below.) we obtain a loop of prompt
authentification but never receive a 403 response. I have tried to
use the
cache_peer_access statement with the cache_peer connect-fail-limit
without success.
connect-fail-limit is TCP/UDP/ICMP level connectivity errors. Auth
being denied is a successful HTTP transaction response, the remote end
got the request and handled it, producing a response for the client.
There is a misconfiguration ?
Config looks okay. Constant loop of auth-reject is expected when
receiving constant flow of non-accepted credentials. Which appears to be
what you are describing.
The connect-fail-limit is only on the connect state and in this case
the ERR from
the helper will never be count as a fail for the cache_peer ?
Yes. ERR from helper only prevents the peer being tried at all. Other
routes will be attempted instead (if any).
Otherwise do you have any other solution ?
The solution is for the validating server to be re-written to correctly
impose this 3-strikes limitation. *It* is the node responsible for
generating 403 as one possible result of its auth testing.
For www-auth header that would be the origin server. For proxy-auth
headers that would be squid auth helper handling (missing feature, see
[a] above).
Amos
