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@xxxxxxxxxxxxxxxxxxxxxxx> a écrit: > 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
