hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17884] - Multiple DIGEST authentication attempts with same credentials
Date Fri, 21 Mar 2003 14:58:22 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884

Multiple DIGEST authentication attempts with same credentials





------- Additional Comments From olegk@apache.org  2003-03-21 14:58 -------
>> * The NTLM class is to become package access in the near future, but this 
patch requires it to be public.  Probably should move the NTLM class into the 
auth package.  Final say on when this happens is up to Jandalf but I'm all for 
doing it now while you're refactoring.  Alternatively the NTLM class could be 
rolled into the NTLMScheme class, but it may make the class a bit big.


- My goal, though, was to retain full API compatibility. I agree that NTLM class
does not belong to the root 'httpclient' package and should be moved to
'httpclient.auth' package.


>> * The realm for NTLM has previously been considered to be the hostname of the 
server being connected to.  Without this assumption it is impossible to 
connect to two NTLM servers in parallel and requires work arounds even when 
connecting sequentially.  We could document getRealm to indicate that if it 
returns null, the realm should be considered to be the host name of the 
server, but I would prefer to see the domain name returned by getRealm.

- I discovered this assumption while working on the patch and found it a bit
odd. I have taken care that the modified code does honor this assumption,
however, I'd also prefer NT domain to be returned as authentication realm. This
said, I have confess about being absolutely clueless as far as NTLM protocol is
concerned. I do not know if it is feasible at all. So, help would be appreciated

>> 
* In NTLMScheme, there is a class variable called ntmlchallenge, it probably 
should be ntlmchallenge (note lm/ml difference).

Oooops. Corrected

>> * AuthChallengeParser.extractScheme returns the result in all lower case, 
however getSchemeName() returns the name with varying capitals. It seems 
neater to have AuthChallengeParser.extractScheme().equals(scheme.getSchemeName
()) if the scheme matches the challenge.

Makes sense. Corrected

>> * There's currently no way to register a new scheme to be used, eventually we 
should add one, though pluggable auth modules wasn't scheduled until 2.1 or 
later (the lack of this ability probably renders the above point moot).

- It occurred to me as well. However, pluggable architecture should encompass no
only authentication, but other aspects (pluggable cookie policies, for
instance). This definitely would be too much for the time being. Such redesign
should be preceded by implementation of a better configuration architecture.
Definitely a post-2.0 feature

>> * Authenticator seems to have almost exclusively become a wrapper for 
HttpAuthenticator.  Should we make it a full wrapper and depreciate the class? 
(Definitely don't remove it until after 2.0 though)

- That will be the next step for me, if the patch gets approved

>>* Maybe I'm just up to late but there seems to be some redundant code on line 
216 of Authenticator:

No, it's just silly me ;-)

Many thanks, Adrian, for your input

Mime
View raw message