ASP.NET 中的 CORS 问题

Posted 2023-03-03

【中文标题】ASP.NET 中的 CORS 问题

【英文标题】：Issues with CORS in ASP.NET

【发布时间】：2015-02-07 00:05:49

【问题描述】：

我有这个应用程序，我想在 Web.Config 中设置我的自定义标头，唉，这并不总是万无一失的。

  <customHeaders>
    <add name="Access-Control-Allow-Origin" value="*" />
    <add name="Access-Control-Allow-Methods" value="*" />
    <add name="Access-Control-Allow-Headers" value="*" />
  </customHeaders>

上面的集合和它的迭代如

  <customHeaders>
    <add name="Access-Control-Allow-Origin" value="*" />
    <add name="Access-Control-Allow-Methods" value="OPTIONS,GET,PUT,DELETE,POST" />
    <add name="Access-Control-Allow-Headers" value="Authorization,Content-Type" />
  </customHeaders>

在所有情况下都没有为我工作。截至目前，此设置在大约 50% 的测试机器中有效，在其他机器中提供 405 Method Not Allowed。

替代方法是在WebApiConfig.cs 中设置此项，并在Web.config 中取消注释自定义标头。

//Web API Cross origin requests - Enable
  var cors = new EnableCorsAttribute("*", "*", "*");
  config.EnableCors(cors);

为什么会有这么多的歧义，我怎么知道CORS 会一直在哪里工作？我真的很想在 Web.config 上设置 CORS，只是因为我希望在部署的版本中灵活地修改它。

【参考方案1】：

对于阅读本文的任何人，这可能会有所帮助。

即使使用以下启动代码

var cors = new EnableCorsAttribute("*", "*", "GET, POST, PUT, DELETE, OPTIONS");
config.EnableCors(cors);

我必须明确地将动词添加到 Web Api 操作方法中：

[Route("sanity")]
[HttpOptions]
[HttpPost]
public List<PostImportView> Sanity(SanityFilter filter)

    ....

相当无意义和烦人

【参考方案2】：

我相信您的“随机”问题发生是因为您没有处理 PUT 和 Delete 动词的预检 Optionsrequests。

对于上面提到的两个动词，会生成一个额外的请求，Options，Web API 需要对其做出响应以确认它确实已配置支持CORS。

要处理这个问题，您需要做的就是发回一个空响应。您可以在您的操作中执行此操作，也可以像这样在全局范围内执行此操作：

protected void Application_BeginRequest()

    if (Request.Headers.AllKeys.Contains("Origin") && Request.HttpMethod == "OPTIONS")
    
        Response.Flush();
    

添加了此额外检查以确保不会利用设计为仅接受 GET 和 POST 请求的旧 APIs。想象一下，当这个 verb 不存在时，向 API 发送一个 DELETE 请求。结果是不可预测的，结果可能是危险的。

另外，在web.config 中，您应该指定方法而不是使用*

<httpProtocol>
  <customHeaders>
    <add name="Access-Control-Allow-Origin" value="*" />
    <add name="Access-Control-Allow-Headers" value="Content-Type" />
    <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
  </customHeaders>
 </httpProtocol>

【讨论】：

是的，这似乎是个问题。这个问题似乎是随机的，但从我从您的帖子中读到的内容来看，它似乎实际上可能并非如此。你能解释一下原因吗？

添加了这项额外检查以确保配置为仅接受 GET 和 POST 请求的旧 API 不会被利用。想象一下，当这个动词不存在时，将一个 DELETE 动词发送到一个设计的 API。结果不确定，它可能会对该 API 背后的数据造成严重问题。

【参考方案3】：

CORS 没有歧义，您需要考虑几个案例

1- 如果您想为您的 Web API 启用 CORS，请仅使用“Microsoft.AspNet.WebApi.Cors”库。

2- 如果您想为整个网站（包括 Web API、SignalR、..etc）启用 CORS，请使用“Microsoft.Owin.Cors”库。

使用上述 2 中的任何库肯定可以工作，并且 cors 将被启用，现在如果你想配置 url，你可以从你的数据库/配置文件中做到这一点，所以当你的应用程序启动你传递给的 url例如，EnableCors 可以来自数据库/配置文件，但底线是避免将任何 cors 标头添加到 web.config。

要了解为您的 Web API 启用 CORS，您可以查看我的文章 here，它为 Web API 启用 CORS 并从 AngularJS 客户端使用它。

希望对您有所帮助。