IIS 劫持 CORS 预检选项请求

编程入门 行业动态 更新时间:2024-10-28 04:21:46
本文介绍了IIS 劫持 CORS 预检选项请求的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧! 问题描述

我正在发出 CORS POST 请求并将 Content-Type 标头设置为 json.这会触发 Preflight OPTIONS 请求以触发(这是好的和预期的)

I am making a CORS POST request and setting the Content-Type header to json. This triggers a Preflight OPTIONS request to fire (this is good and expected)

此 OPTIONS 请求以 200 OK 响应,但这不是来自我的 WebAPI 应用程序.

This OPTIONS request is responded to with a 200 OK but this isn't coming from my WebAPI application.

我有一个自定义的消息处理程序,它永远不会被命中,因此似乎在命中 ASP.NET 之前,IIS 会响应该请求.

I have a custom Message Handler in place and it never get's hit so the request is getting responded to by IIS prior to hitting ASP.NET it seems.

我找到了几篇关于这个主题的帖子,他们说了以下内容

I have found several posts on the subject and they say the following

  • 确保 WebDav 已卸载/删除/禁用 - 完成

    确保 OPTIONSVerbHandler 被删除/更改为使用 aspnet_isapi.dll - 两者都尝试了

    Make sure the OPTIONSVerbHandler is removed / changed to use aspnet_isapi.dll - TRIED BOTH

    确保 extensionlessURLHandler 包含 OPTIONS 动词 - DONE

    Make sure the extensionlessURLHandler includes the OPTIONS verb - DONE

    但是,我的选项请求仍然被劫持.我的意思是,IIS 以 200 OK 响应,但在响应中不包含 Access-Control-Allow-Origin 标头.它不包含此标头,因为它永远不会访问我的 WebAPI CORS 代码来设置此标头.

    However, my options request is still getting hijacked. By that I mean, IIS responds with at 200 OK but isn't including an Access-Control-Allow-Origin header in the response. It isn't including this header because it is never getting to my WebAPI CORS code that would set this header.

    我能找到的两个最好的帖子听起来像是我的问题

    The two best posts I could find that sound like my issue are

    此处:JQuery 卡在 CORS 预检和 IIS 幽灵响应

    在这里:brockallen/2012/10/18/cors-iis-and-webdav/

    我尝试在 IIS 中打开失败请求跟踪 (FERB) 并将其设置为跟踪所有 200 个状态代码.我从来没有看到选项请求被记录......不确定这是否意味着 FERB 不跟踪 OPTIONS 请求,或者我是否需要更改 FERB 设置中的某些内容以使其跟踪 OPTIONS 请求,或者这是否是一个线索我的问题是什么?

    I have tried turning on Failed Request tracing (FERB) in IIS and set it to trace all 200 status codes. I don't ever see the options request being logged... Not sure if this means FERB doesn't track OPTIONS requests or if I need to change something in the FERB settings to make it track OPTIONS requests, Or if this is a clue to what my problem is?

    这是在 IIS 7.5 上运行的 ASP.NET WebAPI 2.0(也在 IIS 8 和 IISExpress 上测试,结果相同)不管什么浏览器(Chrome、FF 和 IE 都以同样的方式失败)

    This is ASP.NET WebAPI 2.0 running on IIS 7.5 (Also tested on IIS 8 and IISExpress with same results) Doesn't matter what browser (Chrome, FF, and IE all fail the same way)

    我已经尝试了我能找到的关于该主题的所有方法,但仍然无法解决我的问题.

    I have tried everything I can find on the subject and still can't fix my problem.

    帮助我 StackOverflow,你是我唯一的希望.

    Help me StackOverflow, you're my only hope.

    推荐答案

    你可以在这里尝试一些事情,所有 web.config 相关,首先修改你的 modules 元素以包含属性 runAllManagedModulesForAllRequests="true",如下:

    A couple of things you can try here, all web.config related, firstly modify your modules element to include the attribute runAllManagedModulesForAllRequests="true", as below:

    <modules runAllManagedModulesForAllRequests="true"> <remove name="WebDavModule" /> </modules>

    然后将您的处理程序设置为以下内容:

    Then set your handlers to the below:

    <handlers> <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" /> <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" /> <remove name="ExtensionlessUrlHandler-Integrated-4.0" /> <remove name="WebDav" /> <remove name="OPTIONSVerbHandler" /> <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%Microsoft.NETFrameworkv4.0.30319aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" /> <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%Microsoft.NETFramework64v4.0.30319aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" /> <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" /> </handlers>

    这应该可以解决问题,但如果没有,作为最后的手段,您可以强制 IIS 使用以下内容输出正确的标头:

    This should do the trick, but if it doesn't, as a last resort you can force IIS to output the correct headers with the below:

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

    注意通配符值,您应该真正将其设置为您的网站将在其上托管的域名.

    Be wary of the wildcard value, you should really set this to the domain name that your site will be hosted on.

  • 更多推荐

    IIS 劫持 CORS 预检选项请求

    本文发布于:2023-10-09 16:39:39,感谢您对本站的认可!
    本文链接:https://www.elefans.com/category/jswz/34/1476222.html
    版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
    本文标签:选项   IIS   CORS

    发布评论

    评论列表 (有 0 条评论)
    草根站长

    >www.elefans.com

    编程频道|电子爱好者 - 技术资讯及电子产品介绍!