Jason Polites wrote:
Thanks Mike.
I confess I didn't read the JavaDoc very thoroughly. Despite your concerns
around caching of Credentials, in the specific case where this loop occurs
the provider is indeed called every time, so maintaining a local count does
the trick.
I look forward to migrating to v4.0 in the near future, so for now all is
good.
Thanks again.
Jason.
Folks,
CredentialsProvider in HC 3.x is utterly and irreparably broken. Avoid
using it for anything other than interactive authentication.
HttpClient 4.0 offers a massively better API and a much, much, much
cleaner code base. There is no point fixing HC 3.x
Oleg
On Wed, Dec 10, 2008 at 2:55 AM, Michael Clark <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
