2

我正在尝试实现一个应用程序，该应用程序使用Taiseer Joudeh在这个非常棒的示例中演示的相同的基于令牌的身份验证机制。

在我的应用程序中，我一直遇到 Cors 问题。在某些配置中，我会在 POST 的预检 (OPTIONS) 请求中收到 500 错误以获取令牌，或者我可以获取令牌，但随后在对实际 API 调用的 GET 请求的预检请求中收到 404 错误不记名令牌。

一个不同之处在于，Taiseer 的代码被设置为托管在 IISExpress（或 Azure）中，而我的代码托管在本地 IIS 上（目前在 Windows 7 上运行）。

凭直觉，我尝试在本地 IIS 下托管他的 API，但发现了完全相同的问题。（令牌的预检请求出现 500 错误，看起来实际的 API 可以正常工作）

从我一直在阅读的内容来看，这似乎是 IIS 中的模块和处理程序与 WebApi 中的 Cors 实现之间存在一些冲突，但是 Taiseer 的实现在托管在 Azure 中时有效，所以这可能是 IIS 版本的差异（我m 当前在 Windows 7 下运行）。

我怎样才能找出导致问题的原因？

4

3 回答 3

2

问题的根源

Token 操作不托管在控制器中，而是内置在较低级别的管道中的某个位置。对该机制的唯一访问是通过GrantResourceOwnerCredentials()扩展类中的覆盖方法OAuthAuthorizationServerProvider。（在我们的例子中是ApplicationOAuthProvider.cs）。

GrantResourceOwnerCredentials()确实有可用的上下文，但它不是作为 PreFlight 请求的一部分调用的，因此您无法为 CORS 插入适当的 PreFlight 响应标头。

解决方案

我们最终确定了以下解决方案。我不是它的忠实粉丝，因为它强制这些标题进入每个响应，但至少它有效。

解决方案是覆盖 Global.asax 中的 Application_PreSendRequestHeaders() 方法以插入适当的标头。

全球.asax.cs

    void Application_PreSendRequestHeaders(Object sender, EventArgs e)
    {
        var origin = Request.Headers.Get("Origin");
        var validOrigins = ConfigurationManager.AppSettings["allowedCorsOrigins"].Split(',');
        if(validOrigins.Any(o => o == origin))
        {
            Response.Headers.Set("Access-Control-Allow-Origin", origin);
            Response.Headers.Set("Access-Control-Allow-Credentials", "true");
            Response.Headers.Set("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization, withcredentials, Prefer");
            Response.Headers.Set("Access-Control-Expose-Headers", "Claims, *");
            Response.Headers.Set("Access-Control-Max-Age", "600");
            Response.Headers.Set("Access-Control-Allow-Methods", "GET,PUT,POST,DELETE,OPTIONS");
        }
    }

这需要以下 web.config 条目：

网络配置

<configuration>
  <appSettings>
    <add key="allowedCorsOrigins" value="http://www.allowedsite1.net,http://localhost:22687" />
    <add key="allowedCorsMethods" value="get, post, put, delete, options, batch" />
    <add key="allowedCorsHeaders" value="*" />
  </appSettings>
...
</configuration>

循环搜索有效来源的原因是您无法使用允许的来源列表进行响应...

这解决了大多数问题，但有一个例外（如果我没记错的话是 PUT 和 DELETE 动词的问题）。这需要删除“ExtensionlessUrlHandler-Integrated-4.0”并在 web.config 的处理程序部分中使用路径和动词重新添加它。

web.config（第二次更改）

<system.webServer>
    <handlers>
        <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
        <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="" />
    </handlers>
    ....
</system.webServer>

与 CORS 相关的有用链接

于 2016-06-21T16:46:58.027 回答
2

它不是您使用的 IdentityServer，但可能是同样的问题。关于 IdentityServer 的Github 页面，您必须在 IIS 下运行时为您的应用程序激活 RAMMFAR (runAllManagedModulesForAllRequests)。

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
  </modules>
</system.webServer>
于 2016-04-20T08:12:14.667 回答
1

我有同样的问题，我按照汤姆霍尔先生的建议做了一切。但是 chrome 仍然报告没有 Access-control-allow-origin 标头存在..在与 fidler 进行检查后，我意识到我的请求通过代理服务器，并且我的代理服务器正在处理预检选项请求..

所以在“互联网选项”中，我删除了代理服务器，发现一切正常......！！！

于 2016-11-03T16:30:48.450 回答