Question

适合模型视图演示者设计模式的安全性和角色授权最合适的位置在哪里？

是否所有实现安全性的页面都实现了特定的接口，比如说IAuthorizedView

public interface IAuthorizedView : IView
{
    IUser user;
    void AuthorizationInitialized();
    void AuthorizationInvoked();
}

然后在演示者级别内处理

public abstract class Presenter<TView> where TView : IView
{
    public TView View { get; set; }

    public virtual void OnViewInitialized()
    {
    }

    public virtual void OnViewLoaded()
    {
    }
}

public abstract class AuthorizationSecuredPresenter<TView> 
                        : Presenter<TView> where TView : IAuthorizedView 
{
    public override void OnViewInitialized()
    {
        View.AuthorizationInitialized();
        base.OnViewInitialized();
    }

    public override void OnViewLoaded()
    {
        View.AuthorizationInvoked();
        base.OnViewLoaded();
    }
}

这是我的第一个想法，唯一的问题是，如果我们从单纯的网络迁移并添加任何类型的API，需要在服务级别上进行授权，那么最终会出现很多重复访问检查或完全可以接受验证两次并且应该预先设计好吗？

Answer 1

您可能需要考虑以下事项。

我会使用装饰器模式分别授权对你的对象的每次调用。

假设你有以下课程：

public class MyService
{
    public virtual void DoSomething()
    {
        //do something on the server
    }
}

然后，您将继续创建一个基础装饰器来实现默认构造函数，如下所示：

public class MyServiceDecoratorBase : MyService
{
    public MyServiceDecoratorBase(MyService service)
    {
    }
}

设置完成后，您可以通过创建这样的授权装饰器来开始装饰：

public class MyServiceAuthorizationDecorator : MyServiceDecoratorBase
{
    private readonly MyService _service;
    public MyServiceDecoratorBase(MyService service)
    {
        _service = service;
    }

    public override void DoSomething()
    {
        //TODO: Authorize the user here.
        _service.DoSomething();
    }
}

所以现在已经完成了主要课程......你怎么打电话给所有这些？简单！

MyService service = new MyServiceAuthorizationDecorator(new MyService());
service.DoSomething();

现在......所有这一切的优势在于您的授权逻辑与主服务（或对象）逻辑完全分离。为什么这很重要？可测性。您可以独立于授权逻辑测试主服务。这对应于开/关原则。

现在，假设您要计算那些讨厌的方法的性能...添加装饰器！日志记录？另一个装饰者！他们都可以这样链接。当然，你添加的越多，越重，但我认为它的优势是值得的。

Answer 2

你的设计看起来很好;至于你的结论性问题......

如果我们从单纯的网络和添加了所需的任何类型的API 服务级别的授权那会有很多结果重复访问检查或是完全可以接受验证两次，应该设计为up 前？

答案强调是 - 您甚至可能希望更频繁地验证权限，即使这些检查是半冗余的。我至少可以想到三次在典型的Web应用程序中检查安全性（具有基于角色的安全性要求）：

首先，在业务层内 - 确保无论执行上下文如何都应用安全性。
其次，在创建视图本身（或其演示者）时，确保用户只能看到他们有权限的功能非常重要 - 出于安全原因，他们不会浪费时间。
第三，构建菜单时确保用户看不到他们无权使用的功能。同样，这是出于安全性和可用性的原因。如果您可以提供帮助，您不希望分散用户无法使用的功能。

Answer 3

View应该只处理UI。它应该设置对话框/表单/控件，但是你需要它。当用户尝试授权将数据传递给演示者时。

然后，演示者应该获取该数据并使用从模型中公开的API和模型对其进行验证。

在我的CAD / CAM应用程序中，实际的API位于应用程序组件的最低应用程序中。我在它周围进行包装和接口，这样如果我有机会使用我的安全API，则上层没有看到任何不同的东西。实用程序告诉我输入的信息是否有效以及授予此人的安全级别。

更具体取决于您使用的确切安全API。

使用模型视图演示者设计模式的安全性和角色授权

3 个答案: