RE: External group concept

> > I think both should match a single ACL type "group" if possible.
>
> Yes. Both a and b need a "group" concept in squid. Adding users to
> groups needs a global API of some sort - probably one function to add,
> one to test for membership and one to free. After that coding a is
> trivial for any given scheme.
>
> IMO the groups shouldn't be a separate ACL type though - the
> proxy_auth
> acl is effectively a group acl now, just not dynamic as users
> login. I'd
> like the list of proxy_auth acl's to be extended as users login, and
> users added and removed from the acl's as they login and are cleaned
> from the user cache respectively.

I am quite ambivalent on this, so I'll try to think in terms of
implementation. The problem is WHEN we determine that an user
is part of a group. You seem to imply that it should be
externally driven (i.e. at reconfiguration). I'd rather do it lazily.
Begin that so, it still must be decided how to determine group membership.
Should squid pass the helper the user's details and receive an enumeration
of the groups the user belongs to? Or should it pass a group name and
receive an enumeration of the user the group contains? Or again should it
send a couple user/group and get a simple "belongs/doesn't belong"?

Having a "group" ACL would help in having a cleaner request path IMO,
because squid would know what to do before having checked the users'
credentials.

-- 
	/kinkie