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

ale*_*lex 17 asp.net-web-api asp.net-web-api2

在Web API 2中启用跨源请求共享似乎有两种功能上不同的方法.

一种是导入System.Web.Http.Cors,使用属性修饰控制器EnableCorsconfig.EnableCors()在WebApiConfig中写入:

[EnableCors(origins: "http://111.111.111.111", headers: "*", methods: "*")]
public class GenericController : ApiController
{
    // etc.
Run Code Online (Sandbox Code Playgroud)

另一种是修改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="*" />
Run Code Online (Sandbox Code Playgroud)

这两种不同方法之间是否存在功能差异?哪一个是正确的 - 这些不是完成同样的事情吗?如果两种方法都用于启用CORS,事情会爆发吗?

Ste*_*n V 12

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

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

至于哪种方式更好?我喜欢使用属性在应用程序代码中保留这些设置,因此这些设置对于未来的开发人员来说是显而易见的.根据您的需要,您可能需要查看CorsApiController主要ApiControllers可以继承的抽象,以反复提供相同的CORS标头.但是,如果CORS标头需要在不同控制器之间或从操作变为动作,则此方法将不起作用.

  • @Kyle 完全不同的策略。选择其中之一。在 web.config 的情况下,您不能为可接受的来源列表设置 `Access-Control-Allow-Origin` 标头。 (2认同)