lör 2011-12-17 klockan 17:54 +1300 skrev Amos Jeffries:
> This adds a %un token (different to %LOGIN and %EXT_USER) which passes
> any pre-known username details to the external ACL helper. But does not
> trigger or require authentication verifications.
A think a better approach to the last part is to add an general acl
flag, indicating that this acl should not trigger auth (or ident?) even
if referencing authenticated(/identified) user names.
The underlying problem is in acl processing in general, not specifically
external acls.
> This will not process auth headers if presented but not yet
> authenticated. But it will allow IDENT and external ACL out-of-band
> authorization usernames to be sent to the helper.
It should probably process auth headers if presented, but not challenge
for authentication if no headers at all are presented.
Note: EXT_USER and USER_CERT_* both do not trigger any
auth/identification events.
> On the upside it will solve some of the cases where people want to
> process usernames without accidental auth challenges.
Well, that is already possible in most cases by careful usage of acls.
> On the downside I am expecting some small amount of confusion as admin
> send HTTP auth headers and expect Squid to magically understand them
> without doing any auth processing.
?
Regards
Henrik
Received on Sat Dec 17 2011 - 11:36:26 MST
This archive was generated by hypermail 2.2.0 : Sat Dec 17 2011 - 12:00:08 MST