Re: external ACL

Robert Collins wrote:

> > Or 4, make challenge processing/generation/IP verification more cleanly
> > separated from the proxy_auth ACL match.
>
> I've no objection to tweaking/refactoring/whateveryouwanttocallit the
> abstraction. It's not quite right as it is. I have some pending work in ntlm
> that will affect such rearrangements - I'll try and get it finished up asap,
> and see if I can rearrange the logic at the same time.

Good.

> I don't think the IP verifcation should be tied to the authentication too
> tightly - the whole point of external acl's as I understood was to allow
> more custom processing. Thoughts here?

We can split it by moving the IP check to it's own ACL. The main reason
to why it is merged into proxy_auth is because it was very simple to do
so at the time.

Actually, splitting it is probably a good idea. Both from a code
perspective and from a configuration perspective. The code gets cleaner,
and the configuration more flexible.

The strict mode is fairly straight forward to implement. Simply have a
ACL that denies accesses from another IP while the IP TTL is still
fresh.

The "automatic" mode where the user credentials are rejected once per
new IP is more troublesome to implement separately, but I am not sure we
really need it either, especially not considering that some browser
versions apparently automatically resubmits the same credentials one
more time even if rejected.. (if someone could explain the logics behind
resubmitting exactly the same credentials as was rejected I would be
glad to know..)

If split, we would end up with 3 ACL types that require a valid
authenticated user id (proxy_auth, proxy_auth_regex, one_ip_per_user)
plus the external ACL type that may require a valid authenticated user
id.

--
Henrik