[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168688#comment-14168688
]
Michael Osipov edited comment on HTTPCLIENT-1545 at 10/12/14 3:53 PM:
----------------------------------------------------------------------
bq. There was a case in the original code where it was possible to get an
infinite loop if {{InitializeSecurityContext}} returned an error (doesn't
matter what error, I just chose {{SEC_E_DOWNGRADE_DETECTED}} because it
happened in my environment). I fixed it and added this test case to make sure a
regression for this error doesn't happen again.
Understood, that is why I would rather throw {{SEC_E_TARGET_UNKNOWN}}.
bq. However, before 1619373, it was using the provided service principle name
(which in the default case through WinHttpClients would have been null) OR the
username.
It is a misconception to pass the current username as SPN or pass a
null/non-null SPN to a factory at configuration time. This is a purely
runtime-related parameter which must be retrieved from the context only. It
makes [this
pass|https://github.com/apache/httpclient/blob/trunk/httpclient-win/src/main/java/org/apache/http/impl/auth/win/WindowsNegotiateSchemeFactory.java#L57]
obsolete.
bq. Our server based authentication provider only supports Kerberos and not NTLM
Neither is correct. Please have a look
[here|https://github.com/apache/httpclient/blob/trunk/httpclient-win/src/main/java/org/apache/http/impl/client/WinHttpClients.java#L71].
NTLM and SPNEGO are supported. Kerberos is not directly supported. Are you
referring to your setup at work? If so, I have a bigger range of servers
available for testing here.
Anyway, I will try all of that stuff next week at work and see how it behaves.
was (Author: michael-o):
bq. There was a case in the original code where it was possible to get an
infinite loop if {{InitializeSecurityContext}} returned an error (doesn't
matter what error, I just chose {{SEC_E_DOWNGRADE_DETECTED}} because it
happened in my environment). I fixed it and added this test case to make sure a
regression for this error doesn't happen again.
Understood, that is why I would rather throw {{SEC_E_TARGET_UNKNOWN}}.
bq. However, before 1619373, it was using the provided service principle name
(which in the default case through WinHttpClients would have been null) OR the
username.
It is a misconception to pass the current username as SPN or pass a
null/non-null SPN to a factory at configuration time. This is a purely
runtime-related parameter which must be retrieved from the context only. It
makes [this
pass|https://github.com/apache/httpclient/blob/trunk/httpclient-win/src/main/java/org/apache/http/impl/auth/win/WindowsNegotiateSchemeFactory.java#L57]
obsolete.
bq. Our server based authentication provider only supports Kerberos and not NTLM
Neither is correct. Please have a look
[here|https://github.com/apache/httpclient/blob/trunk/httpclient-win/src/main/java/org/apache/http/impl/client/WinHttpClients.java#L71].
NTLM and SPNEGO are support. Kerberos is not directly supported.
Anyway, I will try all of that stuff next week at work and see how it behaves.
> Possible infinite loop when WindowsNegotiateScheme authentication fails
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1545
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1545
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.4 Alpha1
> Environment: Windows
> Reporter: Ka-Lok Fung
> Fix For: 4.4 Beta1
>
> Attachments: HTTPCLIENT-1545.WinXP.diff, HTTPCLIENT-1545.patch.diff,
> HTTPCLIENT-1545.v2.patch.diff
>
>
> When {{WindowsNegotiateScheme}} authentication fails, it's possible for
> HttpClient to retry the authentication in an endless loop because the
> {{continueNeeded}} flag is not set to {{false}} when authentication fails.
> One possible way of causing authentication to fail is to use a service
> principle name that is outside your Windows domain (e.g., HTTP/EXAMPLE.COM).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
