【问题标题】:Issues with CORS in ASP.NETASP.NET 中的 CORS 问题
【发布时间】: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,只是因为我希望在部署的版本中灵活地修改它。

【问题讨论】:

    标签: c# asp.net-mvc asp.net-web-api cors http-status-code-405


    【解决方案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】:

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

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

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

      protected void Application_BeginRequest()
      {
          if (Request.Headers.AllKeys.Contains("Origin") && Request.HttpMethod == "OPTIONS")
          {
              Response.Flush();
          }
      }
      

      添加了此额外检查以确保不会利用设计为仅接受 GETPOST 请求的旧 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 客户端使用它。

      希望对您有所帮助。

      【讨论】:

        猜你喜欢
        • 2020-09-08
        • 2014-12-18
        • 2015-03-30
        • 2020-10-28
        • 2019-08-29
        • 2017-08-25
        • 2020-12-06
        • 2018-06-22
        • 2021-10-27
        相关资源
        最近更新 更多