Sebastiaan van Erk wrote:
Oleg Kalnichevski wrote:
Sebastiaan van Erk wrote:
Hi Oleg,
Thanks for your reply.
There's a good chance I'm going to have to get this working, even if it
means I'm going to have to delve into this myself. I'll contact the
original developer and see if he sees anything obvious, but in any case,
if I succeed in getting it working, I will happily contribute the
patches.
Best regards,
Sebastiaan
Hi Sebastiaan
Cool. In my turn I will happily help with HttpClient specific stuff.
Hi Oleg,
I also found the reason why the redirect doesn't work. Basically it
comes down to the following:
The Kerberos auth can have a sequence of challenge/responses, that keep
resulting in 401 until the authentication succeeds. After each
challenge, the authenticate method in the same NegotiateScheme instance
is called, and it processes this new information. So far so good.
But when the request gets redirected to a new URL it basically means the
auth succeeded, and the NegotiateScheme instance is in "ESTABLISHED"
state for the OLD request.
Now the new request also gets a 401, and authenticate is called again,
however, it is called in the OLD instance, for the OLD request.
Basically a *new* instance from the scheme factory is necessary for the
new request.
I can think of two fixes:
1) if http client detects a redirect, it also throws out the old
AuthScheme and uses the auth scheme factory to generate a new one
2) the NegotiateScheme instance detects that the URL has changed by
inspecting the request, and resets its internal state.
I like solution number 1 better, but I'm not sure of what the
consequences might be for the other auth schemes. It seems to me that it
is the right approach though, no matter what the scheme; if you follow a
redirect, just create a new instance.
hhhm. HttpClient should be doing exactly that
http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/client/DefaultRequestDirector.html#999
Another thing I want to look into is if the auth header is reusable for
a specific period of time, so that you can do preemptive auth instead of
a challenge response cycle every time. Not sure if it's possible though,
because that would seen to be open to a replay attack. On the other
hand, one can generate the first token of the negotiation preemptively I
think, assuming the first challenge from the server is empty.
Take a look at how preemptive Digest auth works in 4.1. It might be
similar to what you want:
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
