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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
