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