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 [EMAIL PROTECTED] 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
