Hi,
> I don't see how this is different from the existing acl's. That's
> exactly what they do. If it's database based, loading the acl's from a
> database might be a useful approach. Secondarily extending the
> redirector API to allow a 407 reponse, which squid would then pass on as
> a proxy_auth REQUIRED acl check would allow a generic way of triggering
> proxy auth based on a redirector's rules.
Yeah, its all database based. We call a function from client_side, which
checks to see if access should be allowed. The idea is to keep a large
list of sites you don't want people to goto. (Kinda like the SquidGuard
project, but in testing squidGuard can't fun nearly as fast, besides this
is for internal use).
Now my hope is to continue doing that for everyone, but if a perticular
user log's in, say "joe smo admin" he/she gets immediately returned to
client_side and is not restricted. Now this works great, allready wrote
the functions, wrote an authenticate_program, figured out how to check
who's logged into that session.
> I will gladly provide thoughts as to how you can do what you need to
> cleanly, but at the moment I really don't understand what you are adding
> that is not already there.
Sorry for being too brief, I hope you understand better now. Maybe we're
all crazy over here. :)
Perhaps your suggesting I do something in a squid acl like:
allow everyone
if someone tries to goto url <explicit url> then auth ?
Not sure what the exact ACL syntax would be, but is that what your
recommending to me, rather than trying to do a function call in
client_side shortly after recieving the request?
-- Joe
>
> Rob
>
Received on Thu May 16 2002 - 07:27:33 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:27 MST