Am 2015-04-07 um 14:42 schrieb Oleg Kalnichevski:
On Tue, 2015-04-07 at 14:25 +0200, Michael Osipov wrote:
Am 2015-04-07 um 14:05 schrieb Oleg Kalnichevski:
On Tue, 2015-04-07 at 13:23 +0200, Michael Osipov wrote:
...
Oh, Holy Mother. WWW-Authenticate in a 200 response? Really?
Absolutely, it can happen on any response code, at least 2xx and 3xx
because HTTP is crappy for that.
...
I fear that this is not enough because it does not suffice to process
the challenge but after that AuthScheme#authenticate must be called to
continue the context. If you say that #processChallange takes in tokens
from the server and #authenticate responds to the server, I have to
rethink about my code/approach. All current schemes are structured the
way I have written the new code.
HTTP auth is defined as challenge / response based by RFC 2617. Even
NTLM respects that. SPNEGO managed to outperform NTLM in terms of
craziness.
This is something I cannot change. Is the previous code snippet a final
solution for now or do you see better way to do this?
Is HttpAuthenticator the only class I need to change?
Michael
Michael
I cannot really say as I know pretty much nothing about SPNEGO and
Kerberos. See what makes sense and do what you deem necessary. We can
think of ways of making that hack (or hacks) less hideous once there is
a working solution.
I am not looking for advice on the Kerberos matter but solely how I can
HttpClient keep looping over the connection/requests regardless of the
status code to complete the authentication. Solely #processChallenge
won't probably work because I might need to return another header.
Anyway, I have a look at HttpAuthenticator again later this day and
maybe I can alter the code in a way it will work.
I imagined this to be easier because of #isConnectionBased and #isComplete.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
