Jason Polites wrote:
We have "solved" this by making our CredentialsProvider implementation maintain an internal record of the number of times it has been called, however on face value the code Commons HttpClient code does not appear to deal with credentials that fail continuously.
Your solution actually does seem to be somewhat in line with the JavaDoc for the CredentialsProvider interface: "It is a responsibility of the custom credentials provider to keep track of authentication attempts and to ensure that credentials known to be invalid are not retried."
However, I see that the CredentialsProvider JavaDoc is also not very clear about explaining the contract on how the CredentialsProvider will be used; specifically: when and how often will the CredentialsProvider#getCredentials method will be invoked? This is not explained, and also there is this comment to be worried about:
"HttpClient will simply store the set of credentials returned by the custom credentials provider in the http state object and will attempt to use these credentials for all subsequent requests with the given authentication scope."
If caching were to happen, it would mean the CredentialsProvider wouldn't be able to properly track the number of times the credentials it had provided were actually used.
A possibly more deterministic solution might be to call HttpMethod#setDoAuthentication(false) on all the methods you execute. This will (to the best of my knowledge) "turn off" HttpClient's automatic handling of authentication challenges. This moves the responsibility for reacting to authentication challenges (e.g. 401s, 407s, ...) into your application logic, where you could maintain and increment a counter.
I agree, however, that some sort of max auth attempts counter internal to HttpClient 3.x would be the nicest of all. Unfortunately, it doesn't seem to be there, and with everyone's energy now focused on HC 4.0, I am not sure if you could expect such a feature to be implemented in the 3.x line. Someone more familiar with the project could probably answer this better than I can.
regards, Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
