通过具有 NTLM 授权的代理向具有基本授权的 Web 服务请求不起作用

发布于 2024-11-12 23:52:59 字数 5686 浏览 2 评论 0 原文

我有一个需要基本授权的 Web 服务和一个需要 NTLM 授权的互联网代理后面的用户。我还有一个表单应用程序,它可以调用 Web 服务,并要求用户提供 Web 服务凭据(与 NTLM 凭据不同)。

我让应用程序配置正常工作(WCF ServiceModel),它使用默认代理凭据,请求正在使用代理进行身份验证,但在使用 Web 服务进行身份验证后,由于某种原因,它不会发送请求正文。

如果我在没有 NTLM 代理的情况下进行本地测试,则该过程有效。抱歉示例太长,但我必须将它们包括在内。

第一个请求:

发送:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM
Proxy-Authenticate: BASIC realm="corporaterealm"
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: close
Content-Length: 1057
Proxy-Support: Session-Based-Authentication

[...]

第二个请求:

发送:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0

接收:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAEAAQADgAAAAFgomiysOwieqrhFEAAAAAAAAAALIAsgBIAAAABQLODgAAAA9DAE8ATQBFAFQATgBFAFQAAgAQAEMATwBNAEUAVABOAEUAVAABABoAVgBJAC0AUgBJAEMASwBEAEMALQAwADAAMQAEABwAYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAMAOABWAEkALQBSAEkAQwBLAEQAQwAtADAAMAAxAC4AYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAUAHABjAG8AbQBlAHQAbgBlAHQALgBsAG8AYwBhAGwAAAAAAA==
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: Keep-Alive
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: Keep-Alive
Content-Length: 1074
Proxy-Support: Session-Based-Authentication

[...]

第三个请求:

发送:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAABAAEABIAAAADgAOAFgAAAASABIAZgAAAAAAAACoAAAABYKIogUBKAoAAAAPQwBPAE0ARQBUAE4ARQBUAFAAYQByAHMAbwBuAEoAVwBTAFIASwAwADQAOAA3ADAAlap7g+mPRMEAAAAAAAAAAAAAAAAAAAAARLAhi5lf3nd+l9xENAcu2W6xf6iJbyM6
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收:

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:09:33 GMT
Cache-Control: proxy-revalidate
Content-Length: 1656
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Proxy-support: Session-based-authentication
Age: 0

[...]

第四个请求:

发送:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0

接收:

HTTP/1.1 400 Bad Request
Date: Tue, 31 May 2011 13:09:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, proxy-revalidate
Content-Length: 0
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Age: 0

我不明白为什么它在第四个请求中不发送信封。两次握手都完成了,所以理论上一切都应该没问题。

当我在没有 NTLM 代理的情况下在本地执行此操作时,信封将按预期发送:

第一个请求:

发送:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收:

HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:31:46 GMT

[...]

第二个请求:

发送:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

接收:

HTTP/1.1 200 OK
Date: Tue, 31 May 2011 13:31:47 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Set-Cookie: ASP.NET_SessionId=svv4i11awg05v1j5viz1impo; path=/; HttpOnly
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 5127

[...]

I have a web service that requires basic authorisation and a user behind an internet proxy that requires NTLM authorisation. I also have a forms application that makes calls to the web service and also asks the user for the web service credentials (which are different from the NTLM credentials).

I got the app configuration working (WCF ServiceModel), it's using the default proxy credentials, the request is authenticating with the proxy, but after it authenticates with the web service it does not send the request body for some reason.

The process works if I test locally without the NTLM proxy. Sorry about the long examples, but I had to include them.

1st request:

Send:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

Receive:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM
Proxy-Authenticate: BASIC realm="corporaterealm"
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: close
Content-Length: 1057
Proxy-Support: Session-Based-Authentication

[...]

2nd request:

Send:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0

Receive:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAEAAQADgAAAAFgomiysOwieqrhFEAAAAAAAAAALIAsgBIAAAABQLODgAAAA9DAE8ATQBFAFQATgBFAFQAAgAQAEMATwBNAEUAVABOAEUAVAABABoAVgBJAC0AUgBJAEMASwBEAEMALQAwADAAMQAEABwAYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAMAOABWAEkALQBSAEkAQwBLAEQAQwAtADAAMAAxAC4AYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAUAHABjAG8AbQBlAHQAbgBlAHQALgBsAG8AYwBhAGwAAAAAAA==
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: Keep-Alive
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: Keep-Alive
Content-Length: 1074
Proxy-Support: Session-Based-Authentication

[...]

3rd request:

Send:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAABAAEABIAAAADgAOAFgAAAASABIAZgAAAAAAAACoAAAABYKIogUBKAoAAAAPQwBPAE0ARQBUAE4ARQBUAFAAYQByAHMAbwBuAEoAVwBTAFIASwAwADQAOAA3ADAAlap7g+mPRMEAAAAAAAAAAAAAAAAAAAAARLAhi5lf3nd+l9xENAcu2W6xf6iJbyM6
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

Receive:

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:09:33 GMT
Cache-Control: proxy-revalidate
Content-Length: 1656
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Proxy-support: Session-based-authentication
Age: 0

[...]

4th request:

Send:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0

Receive:

HTTP/1.1 400 Bad Request
Date: Tue, 31 May 2011 13:09:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, proxy-revalidate
Content-Length: 0
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Age: 0

I don't understand why it doesn't send the envelope in the 4th request. The two handshakes are done, so theoretically everything should be fine.

When I do this locally without the NTLM proxy, the envelope gets sent as expected:

1st request:

Send:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

Receive:

HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:31:46 GMT

[...]

2nd request:

Send:

POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>

Receive:

HTTP/1.1 200 OK
Date: Tue, 31 May 2011 13:31:47 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Set-Cookie: ASP.NET_SessionId=svv4i11awg05v1j5viz1impo; path=/; HttpOnly
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 5127

[...]

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

会傲 2024-11-19 23:52:59

我必须更改服务器安全配置以接受摘要式身份验证。由于某种原因,它可以工作,而 Basic 则不能。

I had to change the server security configuration to accept Digest authentication. For some reason that works while Basic doesn't.

久随 2024-11-19 23:52:59

我遇到了一个潜在的类似问题,并且相信在我的情况下,这可能与建立到代理的原始 NTLM 连接有关。

根据我的经验,我每小时都会收到三个按顺序发出的请求,并配置了重试。

在这些请求中,有两个可以工作,一个会失败并返回 400,然后当第一个重试时,它也可以工作。

此处确定 IE 存在类似问题:http://blogs.msdn.com/b/asiatech/archive/2012/01/30/400-bad-request-when-posting-webservice-or-wcf-request-from-ie。 我运行了一些网络跟踪

并观察了行为,并注意到 TCP 流似乎经常被共享,因此其中一个请求最终会向代理发送 NTLM 身份验证消息(零内容长度)在对方已经验证之后。在这种情况下,代理仅传递零内容消息(因为流已经经过身份验证)。

对我来说解决这个问题的方法是转移到 WCF-Custom customBinding (使用 textMessageEncodingmessageVersionSoap11 来保持我的 basicHttpBinding 行为)并(不确定是否需要)将 keepAliveEnabled 设置为 false。

不幸的是,我怀疑这对您的具体情况有多大帮助,但更多信息总没有坏处。

I encountered a potentially similar issue and believe in my case this may be related to the establishment of the original NTLM connection to the proxy.

In my experience I had three requests going out in sequence each hour, with a retry configured.

Of these requests two would work, one would fail with a 400, and then when the first retried it worked as well.

There is a similiar issue with IE identified here: http://blogs.msdn.com/b/asiatech/archive/2012/01/30/400-bad-request-when-posting-webservice-or-wcf-request-from-ie.aspx

I ran some network traces and watched the behaviour and noticed that often the TCP Streams seemed to get shared, so that one of the requests would end up sending an NTLM authentication message (the zero content length) to the proxy after the other had already authenticated. In this situation the proxy just passed through the zero content message (as the stream had already authenticated).

What fixed it for me was moving to a WCF-Custom customBinding (using textMessageEncoding with a messageVersion of Soap11 to maintain my basicHttpBinding behaviour) and (not sure if required) setting keepAliveEnabled to false.

Unfortunately I doubt this is much help for your particular situation, but more info never hurts.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文