[squid-users] How to execute external helpers for each request ?

[hoper]

Thanks you very much Alex.

First, the word "immediatly" was a really bad choice of word from me.
I just wanted to say that we don't want to have to restart squid, or the browser,
or to wait for a really long time. 
If the change occurs in the few next seconds, or a few minutes at worst, it's good.

I thought we can do this with a really small TTL
(this explain the auth_param basic credentialsttl 2 minutes).
But even after 5 minutes, the new proxy is still not taken into account :(

> That means disabling caching of authenticated credentials.

You're talking about this page ?
http://www.squid-cache.org/Doc/config/external_acl_type/
I need to add "cache=0" somewhere ?
In the same page, there is another option:
"ttl=n		TTL in seconds for cached results (defaults 1 hour)"
Is it going to help us to acheive our goal if we change this value ?

> It also means that this approach will not work well for bumped HTTP requests
Are you talking about http redirection ? I need more time to understand the impact
and your answer on this subject. 

> yet we have a backburner project to add such support; it is a large change)
Any idea about when we will have this new feature ? Are we talking about a year ?
3 years ? or probably more ? 

Thanks again for your time.

22 juin 2021 16:05 "Alex Rousskov" <rousskov at measurement-factory.com> a écrit:

> On 6/22/21 5:20 AM, hoper at free.fr wrote:
> 
>> We are using a database with a list of user, and the proxy they need to use.
>> 
>> So in squid.conf file, we declare an external acl:
> 
> FYI: Your are not declaring an external ACL. You are declaring an
> authentication helper.
> 
>> -------------------------------------------------
>> auth_param basic program /mydir/myprogram.sh
>> auth_param basic children 10 startup=1 idle=3
>> auth_param basic realm myrealm
>> auth_param basic credentialsttl 2 minutes
>> -------------------------------------------------
>> 
>> program.sh will check the login/password given by the user.
>> again the ones found in the database. And, if the authentication
>> is sucessfull, it also write on stdout the proxy we need to use for this user.
>> 
>> Example (If this user need to use the proxy number 2):
>> OK proxychoice=p2
>> 
>> If the squid configuration file, we also include another file,
>> which look like this :
>> 
>> -----------------------------------------------------------------
>> cache_peer 10.0.0.1 parent 3128 0 no-query no-digest name=proxy1
>> acl p1auth note proxychoice p1
>> cache_peer_access proxy1 allow p1auth
>> http_access allow authenticated p1auth
>> cache_peer_access proxy1 deny all
>> 
>> cache_peer 10.0.0.2 parent 3128 0 no-query no-digest name=proxy2
>> acl p2auth note proxychoice p2
>> cache_peer_access proxy2 allow p2auth
>> http_access allow authenticated p2auth
>> cache_peer_access proxy2 deny all
>> -----------------------------------------------------------------
> 
> The relative order of your cache_peer_access and http_access directives
> may imply that you think that cache_peer_access is applied/decided
> first. In reality, http_access is applied/decided first. This
> configuration change does not affect Squid decisions, but the following
> order would match the reality better:
> 
> acl p1auth note proxychoice p1
> acl p2auth note proxychoice p2
> 
> http_access allow authenticated p1auth
> http_access allow authenticated p2auth
> 
> cache_peer 10.0.0.1 parent 3128 0 no-query no-digest name=proxy1
> cache_peer_access proxy1 allow p1auth
> cache_peer_access proxy1 deny all
> 
> cache_peer 10.0.0.2 parent 3128 0 no-query no-digest name=proxy2
> cache_peer_access proxy2 allow p2auth
> cache_peer_access proxy2 deny all
> 
> BTW, if you want to allow all authenticated users, regardless of their
> cache_peer choice, then you can remove p1auth and p2auth from
> http_access lines.
> 
>> This configuration is working. The parent proxy used by squid is the good one.
>> BUT: If we change the configuration (proxy for a user) in the database,
>> the change is not take into account until we fully restart squid :(
>> (Even squid -k reconfigure does not work).
>> 
>> Please, any ideas ? What can we do to make this "dynamic" ?
> 
> If you want the changes to apply to every received HTTP request, then
> you need to make sure that your authentication helper is called for
> every received request. That means disabling caching of authenticated
> credentials. It also means that this approach will not work well for
> bumped HTTP requests because their authentication information is (or
> should be) inherited from their CONNECT tunnel. You will have to force
> CONNECT tunnels to have at most one request by disabling persistent
> connections, I guess.
> 
> I would also consider separating user authentication from request
> routing. To do that, move the proxychoice=... annotation functionality
> from the authentication helper to the external ACL helper (with caching
> disabled via external_acl_type options). In this approach,
> authentication results can be cached for as long as you want without
> interfering with more up-to-date routing decisions. However, you should
> not use that [slow] external ACL with cache_peer_access lines as
> detailed below).
> 
>> Any change in the database should be taken into account immediatly.
> 
> cache_peer_access does not support slow ACLs (yet -- we have a
> backburner project to add such support; it is a large change). Until
> such support is added, there will always be some delay between obtaining
> routing information (at authentication or external_acl computation time)
> and applying that routing information (at request routing time).
> 
> HTH,
> 
> Alex.
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users