hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Need clarification on the auth backend design for HTTPCLIENT-1625
Date Tue, 03 Mar 2015 07:15:26 GMT
Am 2015-03-02 um 12:31 schrieb Oleg Kalnichevski:
> On Sun, 2015-03-01 at 22:45 +0100, Michael Osipov wrote:
>> Hi folks,
>>
>> I need some design clarification on the HttpClient auth backend.
>>
>> Currently, I trying to figure out how I can plug in connection-based
>> auth best into the code. From reading the docs and the code, this is
>> what I understood now:
>> Client receives a 401/407, looks up the best available
>> AuthSchemeProvider for that. This one creates a scheme implementation
>> instance which does all the hard work.
>>
>> Given that I have a connection-based auth, I need to be sure that the
>> created instance is maintained on the HTTP connection, refed on the same
>> connection when I receive the mutual response from the server back and
>> then finally disposed (important) when I return isCompleted == true.
>> This instance is internally stateful and must be stateful. It must also
>> disposed when the authentication has failed for some reason.
>>
>> I am quite confused by AuthProtocolState and HttpAuthenticator. Latter
>> retains an auth state with the former but I cannot set the former from
>> within my authenticator. Is that opaque to me and I should solely rely
>> on setting isConnectionBased?
>
> Yes, you should.
>
>>
>> In other words: I need to create a GSSContext which is stateful on the
>> HTTP connection and has to be maintained until the context has been
>> successfully established. After that, I have to dispose it explicitly
>> and HttpClient must throw away the scheme instance around that. If
>> further request arrive on that connection later on a new scheme instance
>> must be created by the backend. So, does it simply suffice to implement
>> ContextAwareAuthScheme, AuthSchemeProvider and AuthSchemeBase properly?
>>
>
> Yes, it does. This works with NTLM which is connection-based, stateful
> and involves multiple auth handshakes. It should also work for GSS
> auth.

Awesome, both sound just the way I need it.

Just to be clear: AuthScheme instance is nulled and GCed as soon as auth 
fails or succeeds? I do not need to cache my GSSContext in the 
HttpContext? What about the UserTokenHandler? Do I need to provide some 
principal back after successful auth, if yes how do I pass that?

>> Further questions:
>>
>> 1. Why does MalformedChallengeException not extend
>> AuthenticationException though it is documented for authentication purposes?
>
> MalformedChallengeException signals syntax violation of some sort
> presenting the client from understanding the challenge whereas
> AuthenticationException signals inability or unwillingness to respond to
> the challenge. To me these are different type of issues, but I am open
> to changing it in 5.0.
>
>> 2. The name of ChallengeState is quite confusing. Where is the state?
>> This is merely a ChallengeHostType.
>
> We can deprecate it and replace with AuthCounterpartType or some such in
> 4.5.

I will simply write down all awkward stuff which cross my path during 
development and will share that afterwards.

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message