1

在 MVC5 之前，我听说过/能够重现过去使用异步操作时 Thread.CurrentPrincipal 并不总是正确设置的问题。这是一篇讨论该问题的博客文章：http ://www.hanselman.com/blog/SystemThreadingThreadCurrentPrincipalVsSystemWebHttpContextCurrentUserOrWhyFormsAuthenticationCanBeSubtle.aspx

现在，我已经使用 .NET 4.5.2 上的 OWIN 中间件在一个新的 Web API 项目中设置了身份验证（使用令牌身份验证提供程序）。Web API 的控制器主要由调用另一个业务层程序集的异步操作组成。我想使用 ClaimsPrincipalPermission 属性来保护对该程序集方法的调用。此属性与检查访问权限的 ClaimsAuthorizationManager 一起使用。我假设在幕后这使用了 Thread.CurrentPrincipal，所以我怀疑我是否会遇到 Thread.CurrentPrincipal 与原始 Web API 调用者不匹配的问题。

我可能会遇到同样的问题吗？到目前为止，我还没有复制它，但我不相信这个问题实际上已经解决了。我认为我更有可能只是还无法重现仍然存在的问题。

参考：

https://msdn.microsoft.com/en-us/library/system.identitymodel.services.claimsprincipalpermissionattribute(v=vs.110).aspx

http://dotnetcodr.com/2013/02/21/introduction-to-claims-based-security-in-net4-5-with-c-part-4-authorisation-with-claims/

4

1 回答 1

0

不确定你是否解决了这个问题，但我只是在一个相当大的项目的故事结尾遇到了这个问题。

我发现发生这种情况的唯一原因是由于我的前端出现编码错误，导致对我的 API 的异步 ajax 调用被发送两次。

处理调用过程的一部分是将声明添加到我的 owinContext 声明原则中。我会假设调用将是线程安全的（或按请求），但我发现第二次调用的声明原则包含第一次调用的声明。我的解决方案是这样的。

设置声明时，从 RequestContext.Principal.Identity NOT owinContext 中检索claimsPrinciple

然后，您可以稍后从 owinContext 阅读业务层中的声明，或者您拥有什么。

我不清楚为什么，也许有人可以详细说明，但它似乎已经解决了这个问题。

于 2015-12-15T05:50:15.857 回答