On 2/05/2012 4:09 a.m., Jason Fitzpatrick wrote:
Hi All
I have a Squid Server (squid-3.2.0.16-1.fc16.x86_64) which is set to
upstream to a 3rd party gateway proxy server and therefore has to
authenticate all users destined for the internet (internal traffic is
not required to authenticate)
Why "therefore"? there is no direct relationship. The above makes no
more sense than "Birds fly, therefore birds have feet". Both might be
true, but there are flying fish and non-flying footed animals.
While this works perfectly from IE and Firefox (NTLM authentication
falling back to basic) chrome clients are unable to authenticate
against the squid at all.
(chrome is the latest version at time of writing 18.0.1025.168 m)
Therefore it is a chrome problem, not a Squid or Firefox or IE problem.
First thing to look at is whether the chrome traffic is actually passing
through Squid and/or the upstream. And what type of traffic it is.
I see the following in the debug logging:
<snipped irrelevant lines>
2012/05/01 16:50:45.674 kid1| ACLChecklist::preCheck: 0x7fdaa23a98c8
checking 'http_access allow AuthorizedUsers'
2012/05/01 16:50:45.674 kid1| Acl.cc(61) AuthenticateAcl: returning 0
sending authentication challenge.
2012/05/01 16:50:45.674 kid1| ACLChecklist::checkForAsync: requiring
Proxy Auth header.
2012/05/01 16:50:45.674 kid1| ACLChecklist::markFinished:
0x7fdaa23a98c8 checklist processing finished
And not much else, does anyone have any suggestions?
The above log shows an auth challenge response being generated. Login
credentials are missing or not validating. 3.2.0.16 does not state which.
Amos
