[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169024#comment-14169024
]
Michael Osipov edited comment on HTTPCLIENT-1545 at 10/13/14 7:04 AM:
--
bq. If you prefer to throw {{SEC_E_TARGET_UNKNOWN}} in the unit test that's
fine. The error code choice is pretty arbitrary.
Personally, I do, that would correspond the the huge comment in the test class.
bq. Even though that 1) it's true that that the SPN should be dynamically
generated and 2) the code is currently tagged as experimental, I'm hesitant to
break an interface that is already used by existing clients of HttpClient-win -
I don't like breaking existing interfaces. I guess we could deprecate that API
first.
Exactly, *experimental* means it is in constant flux, do not rely on it, it
could change/break anytime. This is neither beta or alpha. You have the right
to improve/polish the API.
Regarding server-side support. I have all stuff available, MIT Kerberos with
Subversion on Apache HTTPd, SPNEGO on Tomcat 6 with JGSS and SSPI on Windows
Server. All is available for testing.
was (Author: michael-o):
bq. If you prefer to throw {{SEC_E_TARGET_UNKNOWN}} in the unit test that's
fine. The error code choice is pretty arbitrary.
Personally, I do that would correspond the the huge comment in the test class.
bq. Even though that 1) it's true that that the SPN should be dynamically
generated and 2) the code is currently tagged as experimental, I'm hesitant to
break an interface that is already used by existing clients of HttpClient-win -
I don't like breaking existing interfaces. I guess we could deprecate that API
first.
Exactly, *experimental* means it is in constant flux, do not rely on it, it
could change/break anytime. This is neither beta or alpha. You have the right
to improve/polish the API.
Regarding server-side support. I have all stuff available, MIT Kerberos with
Subversion on Apache HTTPd, SPNEGO on Tomcat 6 with JGSS and SSPI on Windows
Server. All is available for testing.
> 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
[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
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
[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168107#comment-14168107
]
Michael Osipov edited comment on HTTPCLIENT-1545 at 10/11/14 1:26 PM:
--
[~kfung], while this patch makes it work on Windows XP I am confused by the
entire test.
First of all, the SPN should be {{HTTP/example.com}}. This is a hostname, not a
realm. Second, when does {{InitializeSecurityContext}} ever return
{{SEC_E_DOWNGRADE_DETECTED}}? This isn't documented in MSDN. It simply does not
make sense with SPNEGO. It will automatically downgrade from Kerberos to NTLM
if Kerberos is not possible. I just wrote a simple C program on my Windows XP
box. Acquired a Negotiate cred handle, initiated a context for
{{HTTP/example.com}} and received a NTLM type 1 token.
I can of course retry this at work with Windows 7 in our forest environment but
the result should be the same.
was (Author: michael-o):
[~kfung], while this patch makes it work on Windows XP I am confused by the
entire test.
First of all, the SPN should be {{HTTP/example.com}}. This is a hostname, not a
realm. Second, when does {{InitializeSecurityContext}} ever return
{{SEC_E_DOWNGRADE_DETECTED}}? This isn't documented in MSDN. It simply does not
make sense with SPNEGO. It will automatically downgrade from Kerberos to NTLM
if Kerberos is not possible. I just wrote a simple C program on my Windows XP
box. Acquired Negotiate cred handle, intiated context for {{HTTP/example.com}}
and received NTLM type 1 token.
I can of course retry this at work with Windows 7 in our forest environment but
the result should be the same.
> 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
[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168107#comment-14168107
]
Sebb edited comment on HTTPCLIENT-1545 at 10/11/14 12:55 PM:
-
[~kfung], while this patch makes it work on Windows XP I am confused by the
entire test.
First of all, the SPN should be {{HTTP/example.com}}. This is a hostname, not a
realm. Second, when does {{InitializeSecurityContext}} ever return
{{SEC_E_DOWNGRADE_DETECTED}}? This isn't documented in MSDN. It simply does not
make sense with SPNEGO. It will automatically downgrade from Kerberos to NTLM
if Kerberos is not possible. I just wrote a simple C program on my Windows XP
box. Acquired Negotiate cred handle, intiated context for {{HTTP/example.com}}
and received NTLM type 1 token.
I can of course retry this at work with Windows 7 in our forest environment but
the result should be the same.
was (Author: michael-o):
[~kfung], while this patch makes it work on Windows XP I am confused by the
entire test.
First of all, the SPN should be {{HTTP/example.com}}. This is a hostname, not a
realm. Second, when does {{InitializeSecurityContext}} ever return
{{SEC_E_DOWNGRADE_DETECTED}}? This isn't documented in MSDN. It simply does not
make sends with SPNEGO. It will automatically downgrade from Kerberos to NTLM
if Kerberos is not possible. I just wrote a simple C program on my Windows XP
box. Acquired Negotiate cred handle, intiated context for {{HTTP/example.com}}
and received NTLM type 1 token.
I can of course retry this at work with Windows 7 in our forest environment but
the result should be the same.
> 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
[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168107#comment-14168107
]
Michael Osipov edited comment on HTTPCLIENT-1545 at 10/11/14 11:49 AM:
---
[~kfung], while this patch makes it work on Windows XP I am confused by the
entire test.
First of all, the SPN should be {{HTTP/example.com}}. This is a hostname, not a
realm. Second, when does {{InitializeSecurityContext}} ever return
{{SEC_E_DOWNGRADE_DETECTED}}? This isn't documented in MSDN. It simply does not
make sends with SPNEGO. It will automatically downgrade from Kerberos to NTLM
if Kerberos is not possible. I just wrote a simple C program on my Windows XP
box. Acquired Negotiate cred handle, intiated context for {{HTTP/example.com}}
and received NTLM type 1 token.
I can of course retry this at work with Windows 7 in our forest environment but
the result should be the same.
was (Author: michael-o):
[~kfung], while this patch makes it work on Windows XP I am confused by the
entire test.
First of all, the SPN should be {{HTTP/example.com}}. This is a hostname, not a
realm. Second, when does {{InitializeSecurityContext}} ever return
{{SEC_E_DOWNGRADE_DETECTED}}? This isn't documented in MSDN. It simply does not
make sends with SPNEGO. It will automatically downgrade from Kerberos to NTLM
if Kerberos is not possible. I just wrote a simple C program on my Windows XP
box. Acquired Negotiate cred handle, intiated context for {{HTTP/example.com}}
and received NTLM type 1 token.
I can of course retry this at work with Windows in our forest environment but
the result should be the same.
> 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
[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163422#comment-14163422
]
Michael Osipov edited comment on HTTPCLIENT-1545 at 10/8/14 12:33 PM:
--
I am having trouble to pass that test:
{noformat}
---
T E S T S
---
Running org.apache.http.impl.auth.win.TestWindowsNegotiateScheme
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.516 sec <<<
FAILURE! - in org.apache.http.impl.auth.wi
n.TestWindowsNegotiateScheme
testNoInfiniteLoopOnSPNOutsideDomain(org.apache.http.impl.auth.win.TestWindowsNegotiateScheme)
Time elapsed: 5.297 sec
<<< ERROR!
com.sun.jna.LastErrorException: GetLastError() returned 317
at
com.sun.jna.platform.win32.Kernel32Util.formatMessage(Kernel32Util.java:68)
at
com.sun.jna.platform.win32.Kernel32Util.formatMessage(Kernel32Util.java:83)
at
com.sun.jna.platform.win32.Win32Exception.(Win32Exception.java:42)
at
com.sun.jna.platform.win32.Win32Exception.(Win32Exception.java:52)
at
org.apache.http.impl.auth.win.TestWindowsNegotiateScheme$WindowsNegotiateSchemeGetTokenFail.getToken(TestWind
owsNegotiateScheme.java:132)
at
org.apache.http.impl.auth.win.WindowsNegotiateScheme.authenticate(WindowsNegotiateScheme.java:190)
at
org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
at
org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:202)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:262)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:119)
at
org.apache.http.impl.auth.win.TestWindowsNegotiateScheme.testNoInfiniteLoopOnSPNOutsideDomain(TestWindowsNego
tiateScheme.java:115)
{noformat}
Performed on my Windows XP box at home. No domain, just a local machine.
Is that a JNA bug? See {{ERROR_MR_MID_NOT_FOUND: 317}} from
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx
was (Author: michael-o):
I am having trouble to pass that test:
{noformat}
---
T E S T S
---
Running org.apache.http.impl.auth.win.TestWindowsNegotiateScheme
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.516 sec <<<
FAILURE! - in org.apache.http.impl.auth.wi
n.TestWindowsNegotiateScheme
testNoInfiniteLoopOnSPNOutsideDomain(org.apache.http.impl.auth.win.TestWindowsNegotiateScheme)
Time elapsed: 5.297 sec
<<< ERROR!
com.sun.jna.LastErrorException: GetLastError() returned 317
at
com.sun.jna.platform.win32.Kernel32Util.formatMessage(Kernel32Util.java:68)
at
com.sun.jna.platform.win32.Kernel32Util.formatMessage(Kernel32Util.java:83)
at
com.sun.jna.platform.win32.Win32Exception.(Win32Exception.java:42)
at
com.sun.jna.platform.win32.Win32Exception.(Win32Exception.java:52)
at
org.apache.http.impl.auth.win.TestWindowsNegotiateScheme$WindowsNegotiateSchemeGetTokenFail.getToken(TestWind
owsNegotiateScheme.java:132)
at
org.apache.http.impl.auth.win.WindowsNegotiateScheme.authenticate(WindowsNegotiateScheme.java:190)
at
org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
at
org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:202)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:262)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:119)
at
org.apache.http.impl.auth.win.TestWindowsNegotiateScheme.testNoInfiniteLoopOnSPNOutsideDomain(TestWindowsNego
tiateScheme.java:115)
{noformat}
Performed on my Windows XP box at home. No domain, just a local machine.
> Possible infinite loop when WindowsNegotiateScheme authentication fails
> ---
>
> Key: HTTPCLIENT-1545
> URL: http
[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102251#comment-14102251
]
Ka-Lok Fung edited comment on HTTPCLIENT-1545 at 8/19/14 2:41 PM:
--
(Re-opening the issue to get the unit test issue corrected)
The likely reason why it isn't failing is because {{InitializeSecurityContext}}
in {{getToken}} isn't causing a {{Win32Exception}} to be thrown.
By any chance is your Windows machine not joined to a domain, i.e., it's a
member of WORKGROUP? Also, what version of Windows are you using?
I'll try to replicate the issue on a virtual machine that matches the
conditions you specified. In the end, I might be forced to add a JUnit
assumption that the test can only run on Windows machines that is a member of a
domain.
was (Author: kfung):
The likely reason why it isn't failing is because {{InitializeSecurityContext}}
in {{getToken}} isn't causing a {{Win32Exception}} to be thrown.
By any chance is your Windows machine not joined to a domain, i.e., it's a
member of WORKGROUP? Also, what version of Windows are you using?
I'll try to replicate the issue on a virtual machine that matches the
conditions you specified. In the end, I might be forced to add a JUnit
assumption that the test can only run on Windows machines that is a member of a
domain.
> 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 Alpha2
>
> Attachments: HTTPCLIENT-1545.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.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1545) Possible infinite loop when WindowsNegotiateScheme authentication fails
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102251#comment-14102251
]
Ka-Lok Fung edited comment on HTTPCLIENT-1545 at 8/19/14 2:42 PM:
--
(_Re-opening the issue to get the unit test issue corrected_)
The likely reason why it isn't failing is because {{InitializeSecurityContext}}
in {{getToken}} isn't causing a {{Win32Exception}} to be thrown.
By any chance is your Windows machine not joined to a domain, i.e., it's a
member of WORKGROUP? Also, what version of Windows are you using?
I'll try to replicate the issue on a virtual machine that matches the
conditions you specified. In the end, I might be forced to add a JUnit
assumption that the test can only run on Windows machines that is a member of a
domain.
was (Author: kfung):
(Re-opening the issue to get the unit test issue corrected)
The likely reason why it isn't failing is because {{InitializeSecurityContext}}
in {{getToken}} isn't causing a {{Win32Exception}} to be thrown.
By any chance is your Windows machine not joined to a domain, i.e., it's a
member of WORKGROUP? Also, what version of Windows are you using?
I'll try to replicate the issue on a virtual machine that matches the
conditions you specified. In the end, I might be forced to add a JUnit
assumption that the test can only run on Windows machines that is a member of a
domain.
> 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 Alpha2
>
> Attachments: HTTPCLIENT-1545.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.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
