【问题标题】:Custom authorization in ASP.NET as filter or in controller's constructor?ASP.NET 中的自定义授权作为过滤器还是在控制器的构造函数中?
【发布时间】:2013-02-19 20:23:13
【问题描述】:

在我的 ASP.NET Web API 控制器中,我想限制对用户角色的访问。执行此操作的常用方法是扩展 AuthorizeAttribute(exampleexample),然后在我的控制器上撒上我的自定义属性(例如 [AuthorizeUser])。

另一种方法是在控制器的构造函数中添加一个函数。无论如何都需要构造函数,因为我使用的是依赖注入。

这里有一些代码:

public class MyController: ApiController
{
    private IUnitOfWork unitOfWork;
    private IAccountUtils accountUtils;

    // Constructor
    public MyController(
        IUnitOfWork unitOfWork, 
        IAccountUtils accountUtils)
    {
        this.unitOfWork = unitOfWork;
        this.accountUtils = accountUtils;

        // Restrict access to 'User' role
        accountUtils.ThrowExceptionIfUserNotInRole(User.Identity, "User");
    }

    // More code
}

因为有无数教程和示例使用过滤器来授权用户,所以我认为这是最好的方法。但是,当我在调试器中单步执行我的代码时,我发现构造函数方法在过滤器之前被触发。

为了优化代码,如果用户无权访问控制器,尽快中断是有意义的。如果我没记错的话,在构造函数中而不是在过滤器中执行授权应该更有效。我是正确的还是我在这里遗漏了什么?

【问题讨论】:

  • 不建议在非异常情况下抛出异常。也不建议在构造函数中抛出异常,因为用它们很容易让自己陷入困境。最后,此方法绕过了正常的授权管道,这意味着如果您稍后尝试围绕授权进行更微妙的开发,您将与它作斗争。
  • @MystereMan 感谢您富有洞察力的评论。继续您不绕过正常授权管道的想法,我可以看到构造函数方法的另一个问题。当控制器的其余部分受到限制时,我将难以使用 [AllowAnonymous] 属性公开特定操作。
  • 我将其归类为“围绕授权进行更微妙的开发”

标签: asp.net asp.net-mvc authentication asp.net-web-api authorization


【解决方案1】:

您的主要关注点似乎是优化代码,您正确地注意到控制器构造函数在授权过滤器之前运行。但是这两种解决方案之间的性能差异非常很小,应该不会真正影响您的服务。

虽然从构造函数中抛出可能会起作用,但它并不是最优雅的解决方案,因为它需要您在代码中授权,而不是使用属性以声明方式进行授权。它还迫使您将对象实例化逻辑与不那么干净的授权逻辑混合在一起。

所以我建议坚持使用授权过滤器。

【讨论】:

  • 好答案,优素福!你和 Mystere 说服了我,我不会去做令人惊奇的事情,而应该采用经过验证的真实方法。谢谢!
猜你喜欢
  • 2017-04-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-06-09
  • 1970-01-01
相关资源
最近更新 更多