On 12/10/2012 03:06 PM, Amos Jeffries wrote: > On 11.12.2012 07:12, Alex Rousskov wrote: >> On 12/10/2012 09:40 AM, Steve Hill wrote: >>> >>> I posted to the users list last week regarding Squid 3.2.3 breaking >>> Negotiate NTLM authentication. My original report was slightly >>> inaccurate - it looks like the regression was introduced between 3.1.22 >>> and 3.2.0.1. >>> >>> I've been investigating this today using Squid 3.2.3 and found that the >>> problem is that when Auth::Negotiate::Config::fixHeader() is called, >>> authenticateProgram is unset. >> >> FWIW, I have seen that too. I failed to track the exact reason by >> looking at the code alone. Asked around on IRC, but nobody knew what the >> cause could be. My theory was that Squid starts using the wrong Config >> object. Your comments below semi-confirm that. I am waiting for more >> debugging from a customer to triage this further (using a patch with >> extra debugging added). >> >> >>> However, in >>> Auth::Negotiate::Config::decode() is is correctly set. >>> >>> There appear to be two instances of the Auth::Negotiate::Config object: >>> - One instance is instantiated at the top of >>> src/auth/negotiate/auth_negotiate.cc as negotiateConfig and this does >>> _not_ have authenticateProgram set. This is the instance for which >>> fixHeader() is called. >>> - One instance is instantiated elsewhere and has authenticateProgram >>> set. This is the instance for which decode() is called. >>> >>> Unfortunately, comparing the code between 3.1.20 (which works correctly) >>> and 3.2.3 (which is broken), I can't see where authenticateProgram >>> should be set in the negotiateConfig instance. In fact, I don't >>> understand why there are two instances of this object in the first >>> place? >> >> Good question!
> During and after reconfigure there are 2+ Config objects... What if there was no reconfiguration involved? Alex.
