Question

在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，事情会爆发吗？

Answer 1

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

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

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

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

1 个答案: