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 > key=/etc/squid3/certificates/qiodrivekey.key > 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 be sent. > > 2. In the source code of squid (http.c) I see following lines in the function: > > void > copyOneHeaderFromClientsideRequestToUpstreamRequest(const > 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 login=PASS. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
