在 IIS 7 上调用 WCF Web 服务时缺少授权标头
我们有一个 WCF Web 服务，它采用“用户名：密码”授权标头。该服务在我的开发 Windows 7 计算机和生产中的 Windows Server 2003 计算机上运行良好。
但是，我们的开发服务器和新的生产服务器是 Windows Server 2008，并且服务无法接收授权标头。
您可以在下面看到来自 Fiddler 的原始请求，其中包含授权标头。
POST http://servername/service.svc/soap HTTP/1.1
内容类型：text/xml；字符集=utf-8
授权：测试：测试
VsDebuggerCausalityData： uIDPozpQ7mbpOVRFu79Tl0h3mkIAAAAAJMavDzJlIkqyjJDSIIxdVuKNB0y6n29OvukFtyRt0wwACQAA
SOAPAction：“...”
主机：服务器名称
内容长度：152
预期：100-继续
接受编码：gzip、deflate
连接：保持活动状态
我尚未成功启用 IIS 高级日志记录以查看是否可以获得服务器上的任何额外信息。
IIS 网站配置为匿名身份验证。
该服务实现了 IAuthorizationPolicy，并且肯定会调用 Evaluate 方法，这就是缺少授权信息的地方。
感觉好像我在 IIS 中配置了某些错误，但我不知道是什么！任何帮助将不胜感激。
We have a WCF web service that takes a "username:password" Authorization header. This service works fine on my development Windows 7 machine and on a Windows Server 2003 machine in production.
However, our development and new production servers are Windows Server 2008 and the service fails to receive the Authorization header.
You can see the raw request from Fiddler below includes the Authorization header.
POST http://servername/service.svc/soap HTTP/1.1
Content-Type: text/xml; charset=utf-8
Authorization: test:test
VsDebuggerCausalityData: uIDPozpQ7mbpOVRFu79Tl0h3mkIAAAAAJMavDzJlIkqyjJDSIIxdVuKNB0y6n29OvukFtyRt0wwACQAA
SOAPAction: "..."
Host: servername
Content-Length: 152
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
I haven't successfully enabled IIS Advanced Logging to see if I can get any extra information on the server.
The IIS website is configured for anonymous authentication.
The service implements IAuthorizationPolicy and the Evaluate method is definitely being called, which is where the authorization information is missing.
It feels like I've misconfigured something in IIS, but I have no idea what! Any help would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实证明我正在处理两个不同的问题。
在开发服务器上，我发现.NET 4.0 安装已损坏。这是通过这个出色的工具诊断出来的。
在两台服务器上，我将管道模式从经典更改为集成，因为没有人知道为什么首先将其设置为经典。后来对网络配置进行了一些调整，服务就可以正常工作了！
正如 Richard L 所建议的，该解决方案可能还需要基本身份验证，因为生产服务器中缺少该身份验证。请注意，服务网站本身未启用基本身份验证。
几天来试图让这个工作变得非常令人沮丧。
It turns out I was dealing with two different problems.
On the development server, I found that the .NET 4.0 installation was broken. This was diagnosed by this brilliant tool.
On both servers, I changed the pipeline mode from Classic to Integrated, as nobody knew why it was set to Classic in the first place. A few tweaks the web config later, and the service was working!
The solution may also have required Basic Authentication, as suggested by Richard L, since that was missing from the production server. Note that Basic Authentication is not enabled on the service web site itself.
A very frustrating few days trying to get this working.