On 18/06/19 5:01 pm, ngtech1ltd wrote: > I believe that eCAP or ICAP can do the trick for you. > > However I am not sure if it’s a good thing to pass usernames and > password in WWW Http requests. > Only if there are no other peers, and no traffic going direct either. Otherwise you end up broadcasting the users credentials everywhere. Unfortunately that applies to all the header editing by Squid itself as well. On 17/06/19 11:46 pm, Charlie Orford wrote: > Annoyingly, one of our upstream cache_peers requires a fixed string to > be prepended to client usernames. What type of fixed string exactly? > > I'm aware the login= option for cache_peer allows substituting * with > client provided username and appending a fixed string to this. > That is wrong. There is no change to the username at all. "cache_peer ... login=*:foo " takes the username from the client and the password "foo" to login to that peer. The fact that Basic is the only type of login is incidental, and the 'append' an illusion from the Basic auth credential syntax being username then password. Other types may be added in future that use different credential encoding. > Is there a way to achieve something similar if we need to prepend rather > than append a string (perhaps a clever ACL/external_auth trick we could > use to modify client usernames destined for this peer)? > All the ways which come to mind impose unreasonable restrictions. Like Eliezers idea 100% of traffic has to go to that peer or not being able to authenticate the users in your own proxy etc. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
