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