HttpClient的给出了使用

我“逼” HttpClient的做NTLM身份验证使用NTLM身份验证提供商进行协商错误：HttpClient的给出了使用

PoolingHttpClientConnectionManager connPool connPool = new PoolingHttpClientConnectionManager(); 

    Lookup<AuthSchemeProvider> authProviders = RegistryBuilder.<AuthSchemeProvider>create() 
      .register(AuthSchemes.NTLM, new NTLMSchemeFactory())     
      .build(); 

    CloseableHttpClient httpClient = HttpClients.custom().setConnectionManager(connPool).setDefaultAuthSchemeRegistry(authProviders).build();

但是，认证服务器时，我得到一个恼人的日志提示“验证方案协商不支持”。

我该如何摆脱此消息？

（这将在Linux机器上运行，所以的HttpClient 4.4本机认证JNA支持也无济于事。）

来源

2015-02-23 Bob Thule

我也尝试添加： '名单authpref =新的ArrayList（）; authpref.add（AuthPolicy.NTLM）; httpclient.getParams（）。setParameter（AuthPNames.TARGET_AUTH_PREF，authpref）;' 但它给出了相同的消息。上面的代码使用了不推荐使用的API，但我无法找到如何以新的首选方式进行操作。 – 2015-02-23 19:01:09

我认为这完全是很简单的。实际上，客户只愿意执行NTLM，而服务器只愿意执行Negotiate，因此未能就共同的认证方案达成一致。

这是一个如何调整身份验证方案的偏好迫使HttpClient的选择NTLM超过SPNEGO/Kerberos的

RequestConfig config = RequestConfig.custom() 
     .setTargetPreferredAuthSchemes(Arrays.asList(AuthSchemes.NTLM, AuthSchemes.KERBEROS, AuthSchemes.SPNEGO)) 
     .build(); 
CloseableHttpClient client = HttpClients.custom() 
     .setDefaultRequestConfig(config) 
     .build();

来源

2015-02-23 20:33:32 oleg

听起来很聪明 - 但服务器提供Negotiate和NTLM。我还应该提到，身份验证在代码中取得成功，它只是提供恼人的日志消息（并且我认为它需要更长时间进行身份验证，因为它会尝试执行协商身份验证）。 – 2015-02-24 02:55:26

警告消息是代码禁用协商作为受支持的身份验证方案的直接后果。如果您想消除此警告，请不要覆盖默认的一组授权方案提供并使用自定义授权方案偏好代替 – oleg 2015-02-24 10:12:53

太好了 - 所以这个工作，谢谢！我认为，由于不支持认证方案，所以不会考虑。对我来说很奇怪，这不是它的工作方式，但我很高兴你在这里解释。 – 2015-02-24 16:41:27

HttpClient的给出了使用

回答

相关问题