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=24352>. 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=24352 NLTM Proxy and basic host authorization ------- Additional Comments From [EMAIL PROTECTED] 2003-12-08 20:53 ------- The patch also fixes the bug #10792 and provides foundation for fixing the bug #15297. Once the patch is committed, the fix for the said bug will be just a matter of adding a parameter to the HttpClientParams class Changelog: * Plug-in mechanism for authentication modules * AuthModule interface implementing authentication modules can now be instantiated using default (parameter-less) constructor * Authentication modules can now retain limited state information (the state is retained within the lifetime of the method director) * Authentication scheme selection routine can be easily parameterized * Yet another massive refactoring of HttpMethodDirector (Haven't I been a trouble lately?) Still, I am not entirely satisfied with the existing state of authentication framework: * First of all, NTLM & Digest schemes still need to be refactored to take advantage of their new-found capability to maintain authentication state * Secondly, our current strategy is to keep authentication headers as long as they may be useful and to remove them whenever we think (or guess) they may no longer reflect the state of authentication process. It _might_ be better to make authentication scheme smart enough to know what kind of authentication information is required at the given point of the authentication process and to supply authentication headers only when they are really needed * Thirdly, our current approach towards deciding whether an authentication attempt failed or succeeded is kind of screwy. Knowing the state of the authentication process AND the response status code we should be able to tell if authentication has been successful or has failed. Instead we just resort to what is essentially guessing by maintaining a set of supposedly unique tokens/ids/realms/god-knows-whats that represent authentication attempts. Besides, currently we make an assumption that HttpClient may attempt to respond to authorization challenge only once for a given realm and host. With this scheme may get into trouble when trying to bolt interactive authentication on top of it * Finally, we totally neglected ports. Currently ports are not taken into consideration when assigning credentials to the HTTP state, nor when keeping the list of failed authentication attempts Anyways, first things first. Let me know what you think about the patch Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
