On 11.12.2012 13:09, Alex Rousskov wrote:
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?
Before the first reconfigure there *should* only be one Config object
for the auth scheme, from the first configuration loading.
Amos
