通过 Web.config 与 WebApiConfig 和 Controller 属性启用 CORS

Posted 2023-02-14

【中文标题】通过 Web.config 与 WebApiConfig 和 Controller 属性启用 CORS

【英文标题】：Enabling CORS through Web.config vs WebApiConfig and Controller attributes

【发布时间】：2015-07-10 08:04:12

【问题描述】：

似乎有两种功能不同的方法可以在 Web API 2 中启用跨域请求共享。

一种是导入System.Web.Http.Cors，装饰一个控制器带有EnableCors属性，并在WebApiConfig中写入config.EnableCors()：

[EnableCors(origins: "http://111.111.111.111", headers: "*", methods: "*")]
public class GenericController : ApiController

    // etc.

另一个是修改Web.config：

<system.webServer>
     <httpProtocol>
         <customHeaders>
            <add name="Access-Control-Allow-Origin" value="http://111.111.111.111" />
            <add name="Access-Control-Allow-Methods" value="*" />
            <add name="Access-Control-Allow-Headers" value="*" />

这两种不同的方法在功能上有区别吗？哪一个是正确的——这些不是完成同样的事情吗？如果这两种方法都用于启用CORS，事情会不会爆炸？

【参考方案1】：

如果您将标头添加到 web.config，则该应用程序处理的每个请求都将包含指定的标头。此方法在 Web 服务器级别受支持，并且不依赖于正在执行的 config.EnableCors()。您可以使用该方法添加所需的任何 HTTP 标头。

另一方面，EnableCors 属性需要 WebAPI，您需要添加一些代码才能使其工作。对于最终用户来说，结果是一样的。

至于哪种方式更好？我喜欢通过使用属性将这些设置保留在应用程序代码中，因此这些设置对未来的开发人员来说是显而易见的。根据您的需要，您可能希望查看一个抽象的CorsApiController，您的主要 ApiController 可以继承它以一遍又一遍地提供相同的 CORS 标头。但是，如果 CORS 标头需要因控制器或操作而异，则此方法将不起作用。

【讨论】：

有道理 - 所以 System.Web.Http.Cors 命名空间是为了在多个控制器可能需要具有不同跨域请求共享规则的大型项目中增加灵活性。非常感谢！

当你在 web.config 中添加 headers 时，是否仍然需要安装 Microsoft.AspNet.WebApi.Cors 包才能让它们工作？或者这是一个完全独立于安装 nuget cors 包的策略？

@Kyle 完全不同的策略。选择一个或另一个。在 web.config 的情况下，您不能为可接受的来源列表设置 Access-Control-Allow-Origin 标头。

感谢您的信息。如果应用程序需要支持另一个客户端或现有客户端的地址发生更改，则通过 IIS 设置 CORS 策略提供了一种更灵活的方式来配置您的应用程序。

非常有趣的话题，我一直在使用 web.config 为我的 web 应用程序启用 CORS，发现它可以工作，但我认为通过代码启用具有很大的功能和安全性，可能取决于您正在工作的项目, 如果你不太关心 CORS 的范围，我认为更简单的方法是通过 web.config