On 6/22/21 5:20 AM, hoper@xxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
