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

[Alex Rousskov]

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.