autorisation de sécurité et les rôles avec vue modèle design pattern présentateur

Question

Où est l'endroit le plus approprié pour l'autorisation de sécurité et les rôles à tenir dans la vue du modèle modèle de conception du présentateur?

Serait-il pour toutes les pages qui mettent en œuvre la sécurité pour mettre en œuvre une interface spécifique, disent IAuthorizedView qui est le long des lignes de

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

ensuite traitées à l'intérieur du niveau du présentateur

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(); 
    } 
} 

Ce serait mon première idée là-dessus, la seule question que cela me laisse est de savoir si l'on passe de base web uniquement et ajouté tout type d'API qui doit être autorisée par le niveau de service qu'il y aurait finir par beaucoup de duplication de contrôle d'accès ou est-ce parfaitement acceptable de vérifier deux fois et devrait être conçu pour l'avant?

Answer 1

Voici quelque chose que vous pouvez envisager. J'utiliserais le motif décorateur pour autoriser chaque appel à votre objet séparément.

Disons que vous avez la classe suivante:

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

Vous pouvez ensuite procéder à la création d'un décorateur de base pour mettre en œuvre le constructeur par défaut comme ceci:

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

Une fois cette configuration, vous pouvez effectivement commencer à décorer en créant un décorateur d'autorisation comme ceci:

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(); 
    } 
} 

Alors maintenant que les cours principaux sont terminés ... comment vas-tu appeler tout ça? Facile!

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

... Maintenant, l'avantage de tout ce qui est que votre logique d'autorisation est complètement découplée de votre logique service principal (ou objet). Pourquoi est-ce important? Testabilité. Vous pouvez tester votre service principal indépendamment de votre logique d'autorisation. Cela correspond au principe d'ouverture/fermeture. Maintenant, disons que vous voulez calculer la performance sur ces méthodes embêtantes ... ajoutez un décorateur! Enregistrement? Un autre décorateur! Ils peuvent tous être enchaînés de cette façon. Bien sûr, plus on ajoute et plus ça devient lourd, mais je pense que ça vaut le coup pour l'avantage qu'il procure.

Commentaires?

Answer 2

La vue des poignées devrait juste l'interface utilisateur. Il devrait configurer le dialogue/formulaire/contrôles comme vous en avez besoin. Lorsque l'utilisateur tente d'autoriser la transmission des données au présentateur.

Le présentateur devrait ensuite prendre ces données et les valider en utilisant l'API et le modèle exposé à partir du modèle.

Dans mon application de CFAO l'API réelle réside dans le plus bas de mon application l'ensemble utilitaire. Je l'entoure et l'interface autour de lui de sorte que si je devais ma API de sécurité les niveaux supérieurs ne voient rien de différent. L'utilitaire me dit si l'information entrée est valide ou non et quel niveau de sécurité accorder à la personne.

Tout plus spécifique dépend de l'API de sécurité exacte que vous utilisez.

Answer 3

Votre conception semble bien; Quant à votre conclusion question ...

si l'on passe de base web uniquement et ajouté tout type d'API qui a nécessité l'autorisation sur le niveau de service qu'il y aurait beaucoup de finir par duplication d'accès ou de vérification est que parfaitement acceptable de vérifier deux fois et devrait être conçu pour avant?

La réponse est catégoriquement oui - vous pouvez même vérifier les autorisations plus souvent que, même si ces contrôles sont semi-redondants. Je peux penser à au moins trois fois je vérifier la sécurité dans une application Web typique (avec les exigences de sécurité basées sur les rôles):

• Tout d'abord, dans votre couche d'affaires - pour assurer la sécurité est appliquée quel que soit le contexte d'exécution. Deuxièmement, lors de la création de la vue elle-même (ou de son présentateur), il est important de s'assurer que les utilisateurs ne voient que les fonctionnalités pour lesquelles ils ont l'autorisation - pour des raisons de sécurité et pour ne pas perdre de temps. Troisièmement, lors de la construction de menus pour s'assurer que les utilisateurs ne voient pas les fonctionnalités qu'ils n'ont pas l'autorisation d'utiliser. Encore une fois, c'est pour des raisons de sécurité et d'utilisabilité. Vous ne voulez pas distraire les utilisateurs avec des fonctionnalités qu'ils ne peuvent pas utiliser, si vous pouvez l'aider.