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

Fri Jun 25 13:16:56 UTC 2021

Hi again,

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

No, I don't think there is a bug here. 
Because each time my helper is used by squid, it write a line in a dedicated log file.
And it seems to work well. In detail :

Let's say I have a account in my DB with: user1,password1,proxy1
As a client, I start my browser and connect myself with user1/password1

In my helper log file, all is good and I can see that squid used the helper,
and it's answer was "OK proxychoice=proxy1".

Now I switch from proxy1 to proxy2 for user1 in the database.

On my browser, I'm still authenticated as user1, and I'm still use proxy1.
(Ok, that's normal). Later, when the TTL is reached (2 minutes in the configuration I sent),
I can see in my helper's log file that squid used it again. This time, the
answer was : "OK proxychoice=proxy2". So, all seems good here too.

But the routing did'nt change. The parent proxy used after 2 minutes is still proxy1, and
it never change until I restart squid.

I hope to have better explain the problem. So you think there is a bug somewhere,
or do we have a configuration problem ? How can we obtain the result we are looking for ?
(Squid should change the parent proxy if needed after the authentication TTL period). 

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

Do you have a vague idea of the cost of the developement of this feature ?

Thanks again.

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

> 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.
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users