[squid-users] Prepending a string to cache_peer username

[Charlie Orford]

On 18/06/2019 13:15, Amos Jeffries wrote:
> 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?

It's a special meaning string to control how that peer itself further 
routes  traffic.

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

Sorry, I was being brief in my initial email. When I said substituting 
"*" I meant the star is substituted with the client username plus any 
additional text that might be specified to the right of the star. As per 
squid docs: "The star can optionally be followed by some extra 
information which is added to the username."

So if I configure the cache_peer with login=*-foo:bar; and a client 
connects to squid with username "charlie" then the peer will receive 
"charlie-foo" as the username.

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

Actually, in our case this may be acceptable. The user credentials are 
not sensitive and no direct traffic leaves Squid (everything one way or 
another goes out via a peer). We randomly generate them client side and 
have a custom authenticator (using auth_param) that blindly auths 
everything (actual access to squid is enforced by IP address). This 
approach combined with the "userhash" peer selection method allows us 
evenly distribute client traffic across a number of upstream peers but 
gives a client a way to stay with a specific peer if they want to 
(assuming that peer is "up"). We further control the set of upstream 
peers a particular client has access to by using myportname ACLs in 
combination with cache_peer_access ACLs.

It's a strange setup but suits our needs well.