撞倒
所以我一直在修补这个。这是一个带有 IIS 8.5 的新 Windows Server。我从来没有遇到任何问题让 CORS 在 IIS 中“正常工作”,所以我从来不需要关心服务器配置中的繁琐位。直接的解决方法是霰弹枪方法。我通过对 applicationhost.config 的以下修改启用了 CORS 服务器范围
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
但是删除这个 customHeader 并[EnableCors(origins: "*",headers: "*", methods: "*")]
在我的控制器中设置不会导致服务器发回Access-Control-Allow-Origin
响应头(是的,我确保config.EnableCors()
在我的HttpConfiguration
.
另一个复杂情况是,使用这种方法,我必须允许所有来源,因为我需要多个来源才能访问此服务器。浏览器实现不允许在此标头中从服务器发回多个来源。我总是可以在我的应用程序中编写自己的EnableCors
逻辑,但宁愿理解并修复服务器配置以保持在资源上。
原始问题
因此,我在尝试直接从我们的服务器配置团队将 Web 应用程序部署到新的 Windows Server 2012 R2 上的 IIS 8.5 时遇到了一些问题。我的应用程序是启用 Cors 的 Web API(当前允许所有来源),但服务器没有向调用客户端返回 Access-Control-Allow-Origin 标头。我从来没有遇到过 Web API Cors“正常工作”的问题。
我找到了这个资源,但确认 OPTIONSVerbHandler 已在我的应用程序的 web.config 中删除。
我尝试将 customHeader 添加到 IIS,但每当我这样做时,服务器开始返回 500s。
有什么办法可以强制IIS 8.5 从 ASP.NET 发送 Access-Control-Allow-Origin 标头?
编辑1
因此,我显然将 ASP.NET Cross Origin Resource Sharing NuGet 包安装到了我的解决方案中,而不是 ASP.NET Web API 2.2 Cross Origin Resource Sharing NuGet 包中。我把它们换掉了,我的 CORS 功能有限(但仍然出乎意料)。我将描述我现在所经历的怪事。
所以在我意识到我有错误的 NuGet 包之前,我已经进入 applicationHost.config 并添加了
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
试图让服务器手动将标头推回。如果没有 NuGet 更新,这不会在预检响应上设置标题,但此时我不太确定这是否是因为我忘记了 iisreset;我试图快速移动。
无论如何,当我添加Web API 2.2 Cors
NuGet 包时,我的服务器响应开始发出Access-Control-Allow-Origin
带有通配符来源的标头,而不是我在 Web API 路由内的 EnableCors 属性中设置的标头。所以有了这个值,我知道它是配置的 customHeader 而不是EnableCorsAttribute
现在控制该值的。
(这就是奇怪的地方)所以我实际上更希望能够直接在服务器级别直接控制 CORS 白名单,所以我继续将 customHeader 设置为
<customHeaders>
<add name="Access-Control-Allow-Origin" value="http://segment.mydomain.com" />
</customHeaders>
wherehttp://segment.mydomain.com
也匹配我的 API 路由中允许的来源之一。
我现在Access-Control-Allow-Origin
在 PreFlight 请求中从 IIS 得到正确的发回,但随后的 POST 返回 500。如果我EnableCors
从我的 Api Route 中删除该属性,则 POST 成功(通过直接查询保存已发布数据的数据库来确认)
...重量*?
编辑2
因此,这种有希望的方法(在 IIS 中的 customHeader 中静态定义来源,而不是允许开发人员直接在控制器中列出其来源)实际上不会起作用。我需要将多个来源列入白名单,Chrome 的实现只允许在 ACAO 标头中设置一个来源。它也不允许起源中的通配符段,所以......这很糟糕。