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-22 04:23 -------
> - 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.

* That's fine, it can be moved whenever it's ready to move.  I only noticed 
because I'd already made my local copy package private and saw the compile 
errors.

>- 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

* Using the NT domain would be nice, but unfortunately it is one of the things 
stored in the credentials we're trying to find.  Also, a server may be in any 
number of NT domains for authentication purposes, or an entire NT domain could 
be a child of another domain (they form a tree structure).  The one constant 
that I have been able to find in the process, is the host name (which 
unfortunately can be substituted for a different host name or an ip) as with 
no realms any authentication challenge from a server will accept the same 
credentials as any other challenge from that server.  If there is a better way 
to go about it, it would be good to hear about it, but I don't think there is.

The rest we seem to agree on.  I'll try to run a few tests to make sure 
everything is working as expected this afternoon, but it all looks good to me 
so I don't expect any problems.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to