如何在 WSDL 中使用 HTTPS 为卸载 SSL 后面的 WCF 服务配置服务端点

发布于 2025-01-08 12:12:55 字数 857 浏览 1 评论 0 原文

我的部署环境在 IIS 7.5 托管的 WCF 服务前面有 SSL 卸载(和负载平衡)硬件。因此,虽然外部世界将访问

https://mydomain.com/MyService.svc

硬件,将处理 SSL 并将流量转发到

http://myintranet/MyService.svc

但是,当我从外部获取 WSDL(通过添加“?wsdl”)时,WSDL 地址为“http://mydomain.com/MyService.svc" -- 我的公共地址的不安全、非 SSL 版本。

我尝试显式设置listenUri,但收到错误,因为我的站点也需要多个绑定(我在内部可以通过SSL卸载但通过负载平衡器访问它,或者绕过负载平衡器并到达站点)直接):

When 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' is set to true in configuration, the endpoints are required to specify a relative address. If you are specifying a relative listen URI on the endpoint, then the address can be absolute.

我尝试了多种基地址、前缀过滤器、多个端点等的组合,但最终总是出现一个或另一个错误。尽管我用谷歌搜索得最好,但我找不到其他人有这样的设置。

My deployment environment has SSL-offloading (and load-balancing) hardware in front of my IIS 7.5 hosted WCF service. So while the outside world will go to

https://mydomain.com/MyService.svc

the hardware will handle the SSL and forward the traffic to

http://myintranet/MyService.svc

However, when I grab the WSDL from the outside (by tacking on "?wsdl"), the WSDLs address are for "http://mydomain.com/MyService.svc" -- the insecure, non-SSL version of my public address.

I tried explicitly setting the listenUri, but I get an error because my site also requires multiple bindings (I internally can access it beyond the SSL-offloading but through the load-balancer, or bypass the load-balancer and reach the site(s) directly):

When 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' is set to true in configuration, the endpoints are required to specify a relative address. If you are specifying a relative listen URI on the endpoint, then the address can be absolute.

I've tried numerous combinations of baseAddresses, prefix filters, multiple endpoints, etc. but always end up with one error or another. Despite my best Googling, I can't find anyone else with this set up.

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

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

发布评论

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

评论(2

稚气少女 2025-01-15 12:12:55

我忘了我曾问过这个问题。我们最终确实达成了解决方案,尽管已经过去了很长时间,我已经记不清所有细节了。相反,我从现有配置中提取我认为是关键点的信息。

基本上,我们使用的是根据我们在野外找到的示例代码创建的“httpsViaProxyTransport”。这使 WCF 确信它是一种安全传输,尽管它实际上只是 HTTP。

然后在/configuration/system.serviceModel/serviceHostingEnvironment中,我们设置一些baseAddressPrefixFilters。我们设置了 HTTP 和 HTTPS,因为我们有时会在 NLB/SSL 卸载程序后面访问它。

        <baseAddressPrefixFilters>
          <add prefix="http://MyService.mydomain.com/"/>
          <add prefix="https://MyService.mydomain.com/"/>
        </baseAddressPrefixFilters>

I forgot I had asked this. We did eventually arrive at a solution, though it has been so long, I can't remember all of the details. Instead, I'm extracting information from our existing configuration that I believe are the key point.

Basically, we are using a "httpsViaProxyTransport" we created from sample code we found in the wild. This convinces WCF that it's a secure transport even though it's really just HTTP.

Then within /configuration/system.serviceModel/serviceHostingEnvironment, we set some baseAddressPrefixFilters. We set both HTTP and HTTPS because we sometimes access it behind out NLB/SSL-offloader.

        <baseAddressPrefixFilters>
          <add prefix="http://MyService.mydomain.com/"/>
          <add prefix="https://MyService.mydomain.com/"/>
        </baseAddressPrefixFilters>
牵你的手,一向走下去 2025-01-15 12:12:55

我们在让 SSL 卸载与 WCF 配合使用方面遇到了困难。问题是相同的配置开关确定允许的协议(必须是 http)和代理中发出的协议(必须是 https)。我们的答案是放弃 SSL 卸载要求。我们可能太容易放弃了。

如果您比我们更顽强,您可以考虑尝试自定义 WSDL 导出器,如文档所述 这里

We're having a hell of a time getting SSL offloading to work with WCF. The problem is that the same config switch determines allowed protocol (which has to be http) and the protocol emitted in the proxy (which has to be https). Our answer was to drop the SSL offloading requirement. We may have given up too easily.

If you're more tenacious than us, you might consider trying a custom WSDL exporter, as documented here.

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