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?
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?
Further questions:
1. Why does MalformedChallengeException not extend
AuthenticationException though it is documented for authentication purposes?
2. The name of ChallengeState is quite confusing. Where is the state?
This is merely a ChallengeHostType.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
