Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Date: Mon, 21 Apr 2003 08:41:30 +1000
Subject: Re: HTTPClient Ntlm Implementation
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Adrian Sutton <adrian@intencha.com>
To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <4310EEB2-737E-11D7-8E43-000393016056@intencha.com>
Message-Id: <3AFDB670-7381-11D7-8E43-000393016056@intencha.com>

Update:

It's actually a side effect of no longer taking into account the full 
WWW-Authenticate header to tell what we've authenticated against.  
Previously:
WWW-Authenticate: NTLM

and

WWW-Authenticate: NTLM DDIDLAJSSDKSOOS==

were different, whereas now they are considered the same.   A couple of 
possible fixes:
1. Change HttpMethodBase to detect NTLM and deal with it differently.  
(I don't like this)

2. Change NTLMScheme.getRealm() to return the challenge rather than 
null (realms aren't supported by NTLM).  I don't like this much either 
since it violates the contract for getRealm - the upside being that 
getRealm makes no sense in NTLMScheme anyway.

3. Add a new method to AuthScheme getID() which would return the best 
way to uniquely identify the challenge.  So for basic and digest it 
would return getRealm() but for NTLM it would return the challenge 
string or the message type that was sent.  This seems a little 
excessive but would provide a scheme independant way for HttpMethodBase 
to determine if the auth request had already been attempted which may 
be useful when we add support for pluggable authentication schemes.

Any thoughts on this?  Any better ideas?

Adrian Sutton.

On Monday, April 21, 2003, at 08:20  AM, Adrian Sutton wrote:

> Andre,
> As Mike pointed out, the logs didn't come through but I have managed 
> to reproduce the problem.  It looks like the blame lies at my feet 
> actually. :(  The change to how we detected which realms we'd tried to 
> authenticate against is the culprit.  I'll see what I can do to fix > it.
>
> Thanks for the clear problem description.
>
> Adrian Sutton.