Justin Tay wrote:
Hi,
I would like to do the following regarding proxy authentication.
1) Pre-emptive authentication for proxies that have issued a challenge
before. (The idea being that a proxy that has requested for authentication
before will probably still ask for authentication)
2) Allow the handling of failed authentication requests due to incorrect
credentials. (The use case is similar to what happens when the proxy
credentials are wrong in a browser, it will prompt the user for a username
and password and try to authenticate with the proxy again)
For (1) followed the sample that implements HttpRequestInterceptor and was
able to meet the requirement by implementing HttpResponseInterceptor and
storing the HttpHost of the proxy and AuthScheme into a map to be retrieved
later. (BasicScheme only knows it's handling a proxy after a call to
processChallenge). This works fine when connecting to http targets.
However I would also like this behaviour to apply when connecting to https
targets. I notice that this is done in
DefaultRequestDirector.createTunnelToTarget() and doesn't involve the
calling of any interceptors. In any case the execution context isn't
populated till later.
Justin,
The fact that protocol interceptors do not get called when executing
CONNECT methods is clearly a bug. Please open a JIRA issue for this
problem. Preemptive authentication should work for tunneled connections
exactly the same way for the direct ones.
Is there any way to achieve this without extending DefaultRequestDirector?
For (2) is it possible to add one more method to the AuthenticationHandler
like handleAuthenticationFailure? My only other alternative seems to be
extending DefaultRequestDirector and overriding the updateAuthState method.
I think it's best if in additional to the proxyAuthHandler, the
targetAuthHandler can also use this to prompt the user for credentials again
if the user gets it wrong.
This is intentional. Execution of potentially blocking operations such
as UI dialogs inside the main request execution loops is a bad idea,
because such blocking operations will prevent the connection from being
returned to the connection manager for a long period of time.
Interactive user authentication should be implemented on top of
HttpClient services: the caller should detect 401 and 407 status codes,
pop a UI dialog, collect new credentials, update credentials in the
actual CredentialsStore, and retry the request.
Hope this helps
Oleg
Regards,
Justin Tay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
