具有模型视图演示者设计模式的安全性和角色授权答案

【问题标题】：Security and roles authorization with model view presenter design pattern具有模型视图演示者设计模式的安全性和角色授权
【发布时间】：2009-11-12 20:49:19
【问题描述】：

哪里是安全和角色授权最适合模型视图演示者设计模式的地方？

是否所有实现安全的页面都实现特定接口，例如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();
    }
}

这将是我的第一个想法，这会给我留下的唯一问题是，如果我们从仅基于 Web 的移动并添加任何类型的 API，需要在服务级别上进行授权，那么最终会导致大量重复访问检查还是完全可以接受两次验证并且应该预先设计？

【问题讨论】：

标签： asp.net security oop mvp

【解决方案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();

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

现在，假设您要计算那些讨厌的方法的性能...添加一个装饰器！记录？又一个装修工！他们都可以这样被锁住。当然，你添加的越多，它就越重，但我认为它提供的优势是值得的。

评论？

【讨论】：

【解决方案2】：

你的设计看起来不错；至于你的结论性问题......

如果我们从完全基于 Web 的移动和添加了所需的任何类型的 API 服务级别授权最终会有很多重复访问检查或是完全可以接受验证两次，应该设计为前面？

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

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

【讨论】：

【解决方案3】：

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

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

在我的 CAD/CAM 应用程序中，实际的 API 位于我的应用程序的最底层，即实用程序组件。我围绕它进行包装和接口，这样如果我碰巧我的安全 API 上层看不到任何不同。实用程序告诉我输入的信息是否有效以及授予该人的安全级别。

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

【讨论】：