Oleg Kalnichevski wrote:
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 theoriginal 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, SebastiaanHi 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 thathttp://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/impl/client/DefaultRequestDirector.html#999
Ah, but this is only if the target host is different. The problem here is that the target host is the same, but the it's a different resource, so the negotiation must begin anew... (In my test, the redirect is from http://tunneltest.servoy.com/private -> http://tunneltest.servoy.com/private/
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
Thanks for the tip. Will look at it right after I fix the ticket caching issue.
Regards, Sebastiaan
Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
