Question

我需要一个用于业务逻辑类中的自定义授权的工具。它必须是基于权限的系统，但我无法决定如何将授权规则应用于方法。

我的第一个想法是将自定义属性应用于方法

[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
     // some code goes here
}

我的业务逻辑类有接口，因此我可以使用Unity拦截行为，并在运行时检查当前用户是否具有所需权限。如果他没有，则抛出异常。

但现在我担心这种方法的可靠性。

通常是由unity容器注入的业务逻辑类的引用。所以没有问题，因为它被配置为应用接口拦截机制。

但是，如果某些开发人员将直接实例化我的业务逻辑类呢？然后，即使当前用户没有权限进行某些操作，甚至未经过身份验证，他也无法进行任何拦截，并且他将能够调用任何方法。

也有人可以改变统一容器配置，完全关闭拦截扩展。我的授权系统再次无效。

我看到ASP .NET MVC正在使用类似的授权机制。只有在通过标准方式（IController.Execute）提出请求时才应用授权规则。我认为这不是问题，因为控制器（Web用户）的最终用户无法直接访问控制器类。

在我看来，业务逻辑的最终用户是开发前端的程序员，他可以有意或无意地搞砸 - 创建业务逻辑类的实例并调用任何方法。

你能给我什么建议？你是如何处理这类问题的？

谢谢。

Answer 1

.NET Framework支持声明权限验证机制，该机制不依赖于Unity拦截或其他“外部”AOP。为了利用这一点，您的属性必须从System.Security.Permissions.CodeAccessSecurityAttribute继承。 BCL中包含的System.Security.Permissions.PrincipalPermissionAttribute是使用此机制评估用户权限的示例。如果它不符合您的需求，那么就没有什么能阻止您创建自己的属性了。

Answer 2

如果您的构造函数是内部的，并且您的对象是从工厂实例化的，那么开发人员将无法通过错误绕过您的安全性。

如果有人真的，真的想在没有安全性的情况下创建你的objets，他仍然可以使用反射来做到这一点，但这样做是非常有意的。