You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Kalnichevski, Oleg" <ol...@bearingpoint.com> on 2004/03/24 11:55:25 UTC
RE: [PATCH] Yet another refactoring of authentication logic "Oops Idid it again"
Any objections to committing this patch?
Oleg
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Thursday, March 18, 2004 22:54
To: Jakarta Commons HttpClient mailing list; Vincent Massol
Subject: [PATCH] Yet another refactoring of authentication logic "Oops
Idid it again"
Folks,
I believe that most of you have already been suspecting that tinkering
with the authentication framework is a sort of Russian traditional
sport. Well, almost ;-)
Prompted by the 2.0 incompatibility discovered by Vincent Massol
<vmassol at pivolis.com> (Specials thanks go to Gump and all the Gump
Meisters) I went over the authentication code one more time and made yet
another series of changes
* I factored out the authentication challenge processing logic from the
HttpMethodDirector to a class of its own. Thanks to that authentication
challenge processing can now be tested separately. Test cases provided.
* HttpMethodDirector no longer intervenes if Authorization &
Proxy-Authorization are set manually by the user. Custom authorization
headers are never overwritten
* Introduced a new class called AuthState that represents the
authentication process state that contains all the authentication
details. Basically it is just a convenience wrapper around the
authentication scheme interface.
* Proxy and host authentication state objects moved to the HTTP method
level, so that they can be queried by the user to find out the details
about authentication that has been performed by the HttpMethodDirector.
With the current implementation all the details of proxy and host
authentication are contained within the HttpMethodDirector instance,
which exists only within the lifetime of HttpClient#executeMethod()
execution. As soon as the method returns, the respective
HttpMethodDirector instance gets GCed along with the authentication
details
* More test cases
Let me know what you think
Oleg
PS: I hope this is going to be the last round of changes in the
authentication logic. I can live with it now (until 4.0, of course)
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [PATCH] Yet another refactoring of authentication logic "Oops Idid it again"
Posted by Michael Becke <be...@u.washington.edu>.
Hi Oleg,
Sorry, I completely forgot about this one. Could you send the patch
again, or add it to a bug?
Mike
On Mar 24, 2004, at 5:55 AM, Kalnichevski, Oleg wrote:
>
> Any objections to committing this patch?
>
> Oleg
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Thursday, March 18, 2004 22:54
> To: Jakarta Commons HttpClient mailing list; Vincent Massol
> Subject: [PATCH] Yet another refactoring of authentication logic "Oops
> Idid it again"
>
>
> Folks,
>
> I believe that most of you have already been suspecting that tinkering
> with the authentication framework is a sort of Russian traditional
> sport. Well, almost ;-)
>
> Prompted by the 2.0 incompatibility discovered by Vincent Massol
> <vmassol at pivolis.com> (Specials thanks go to Gump and all the Gump
> Meisters) I went over the authentication code one more time and made
> yet
> another series of changes
>
> * I factored out the authentication challenge processing logic from the
> HttpMethodDirector to a class of its own. Thanks to that authentication
> challenge processing can now be tested separately. Test cases provided.
>
> * HttpMethodDirector no longer intervenes if Authorization &
> Proxy-Authorization are set manually by the user. Custom authorization
> headers are never overwritten
>
> * Introduced a new class called AuthState that represents the
> authentication process state that contains all the authentication
> details. Basically it is just a convenience wrapper around the
> authentication scheme interface.
>
> * Proxy and host authentication state objects moved to the HTTP method
> level, so that they can be queried by the user to find out the details
> about authentication that has been performed by the HttpMethodDirector.
> With the current implementation all the details of proxy and host
> authentication are contained within the HttpMethodDirector instance,
> which exists only within the lifetime of HttpClient#executeMethod()
> execution. As soon as the method returns, the respective
> HttpMethodDirector instance gets GCed along with the authentication
> details
>
> * More test cases
>
> Let me know what you think
>
> Oleg
>
> PS: I hope this is going to be the last round of changes in the
> authentication logic. I can live with it now (until 4.0, of course)
>
> ***********************************************************************
> ****************************
> The information in this email is confidential and may be legally
> privileged. Access to this email by anyone other than the intended
> addressee is unauthorized. If you are not the intended recipient of
> this message, any review, disclosure, copying, distribution,
> retention, or any action taken or omitted to be taken in reliance on
> it is prohibited and may be unlawful. If you are not the intended
> recipient, please reply to or forward a copy of this message to the
> sender and delete the message, any attachments, and any copies thereof
> from your system.
> ***********************************************************************
> ****************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org