[squid-users] Query about login=pass
squid3 at treenet.co.nz
Fri Apr 1 18:27:04 UTC 2016
On 2/04/2016 1:40 a.m., Sreenath BH wrote:
> Hi All,
> We have a setup with two squid servers lets say, squid1 and squid2.
> Requests land at Squid1 and it sends the request to squid2. Squid2
> uses X-User-ID and Authorization headers for authenticating the user,
> and on success, fetches data from another webserver and returns the
> data. If authentication fails, it returns a 401 response.
> What we have observed is that for some reason, squid does not send the
> Authorization header to the upstream squid server. However, X-User-ID
> header is always sent to upstre.
X-User-ID is a custom header. It would appear that it is not listed in
the Connection: header, so that makes it an end-to-end feature to be
delivered all the way to the origin server.
This is why Squid passes it onward.
> 10.135.81.100 is squid2.
> Here is configuration of squid1, where we see the problem.
> acl test_upload urlpath_regex ^/upload
> acl test_nms urlpath_regex ^/nms
> acl trash_misc urlpath_regex ^/trash
> http_port 80 accel defaultsite=sitgateway.qiodrive.com vhost
> https_port 443 cert=/etc/squid3/certificates/test.crt
> cafile=/etc/squid3/certificates/gd_bundle-g2-g1.crt accel
You have configured your Squid to be a reverse-proxy. So that it acts as
if it were an origin server and *consumes* the WWW-Auth headers (rather
than the usual Proxy-Auth headers).
> cache_peer 10.135.81.100 parent 80 0 no-query login=PASS originserver name=name1
> cache_peer_access name1 allow test_upload
> cache_peer_access name1 deny all
> cache_peer 10.135.81.100 parent 80 0 no-query login=PASS originserver name=name2
> cache_peer_access name2 allow test_nms
> cache_peer_access name2 deny all
login=PASS will attempt to login with Basic auth credentials to the
peer. If, and only if, Squid has some Basic auth credentials to send.
> cache_peer 10.135.81.100 parent 80 0 no-query originserver name=name3
> cache_peer_access name3 allow trash_misc
> cache_peer_access name3 deny all
> As can be seen above, we have associated different names (name1,
> name2 and name3) for the same Squid2 server, all listening at same
> port also. Is this a correct way of doing it? I ran squid -parse on
> the squid.conf file and it did not report any problem.
> 1. Squid1 listens on both 80 and SSL port. If request comes on SSL
> port, will it send Authorization token to Squid that is not SSL squid?
The two details are not related. So there is not any yes/no answer to that.
For any message, *if* that message is allowed to be sent to the
particular peer, then the headers allowed to be sent to that peer will
> 2. In the source code of squid (http.c) I see following lines in the function:
> HttpHeaderEntry *e, const String strConnection, const HttpRequest *
> request, HttpHeader * hdr_out, const int we_do_ranges, const
> HttpStateFlags &flags)
This function happens long after the auth header is consumed and/or
re-constructed by Squid. It is only relevant to whatever auth headers
Squid has decided to send upstream have been added back into the request.
> I don't understand what might prevent squid from sending the
> Authorization header.
What login=PASS does is tell Squid to use the Basic authentication
credentials it has - either from the Basic authentication helper it is
using to perform auth, or the external ACL helper, or the original
client request (in that order) to login to the upstream peer.
This can be prevented by several things:
* the upstream peer not requesting login.
* no Basic auth credentials being known. eg, if you are not using Basic
auth to the client.
* ICAP/eCAP adaptation stripping away the credentials
To pass on any non-Basic auth credentials use login=PASSTHRU instead of
More information about the squid-users