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

[Alex Rousskov]

On 6/23/21 7:26 AM, hoper wrote:

> 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 :(

If Squid trusts stale user credentials (i.e. allows new requests with
stale cached credentials without revalidating them with your
authentication helper), then this is a Squid bug. Credentials become
stale when their configured (via credentialsttl) TTL expires. The clock
should start ticking when Squid makes the corresponding authentication
helper request.

If you can reproduce this bug with a supported Squid version, then I
recommend filing a bug report. This problem is essentially unrelated to
proxychoice annotations though -- either the authentication helper is
contacted for credentials (re)validation or it is not. It should be
triaged/reported without paying attention to annotations.


>> That means disabling caching of authenticated credentials.

> You're talking about this page ?
> http://www.squid-cache.org/Doc/config/external_acl_type/

In this context, no, I am not. Here, I meant auth_param. As I mentioned
earlier, external ACLs are not related to authentication.


> 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 ?

The configuration you previously shared does not use external ACLs so
changing external ACL cache parameters will affect nothing.


>> It also means that this approach will not work well for bumped HTTP requests
> Are you talking about http redirection?

No, I am talking about SslBump features. Search squid.conf.documented
for letters "bump" to find starting points. If you do not use those
features, then you can ignore that part of my comment.



>> 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 ? 

Insufficient demand for that feature does not allow me to provide a
reliable ETA at this time.

Alex.


> 22 juin 2021 16:05 Alex Rousskov 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.