conception des membres Asp.net MVC

Question

Certains d'arrière-plan pour commencer:

J'ai mis en œuvre une coutume MembershipProvider qui valide un utilisateur de ma couche de service appelé « WebMemberShipProvider »

Actuellement, je suis un service appelé " MembershipService ", ce service implémente l'interface IMembershipService sur la couche de service. cette MemberShipService interroge le dal, et valide un utilisateur en fonction du nom d'utilisateur/mot de passe

J'ai aussi créé une coutume AuthorizeAttribute nommé « AuthorizeOwnerAttribute » et c'est là que je vais avoir des problèmes de conception.

Pour chaque contrôleur, j'ai une dépendance sur un service. par exemple. UsersController prend un IUserService dans son constructeur.

Comment puis-je appeler AuthorizeAttribute sur un ActionResult où l'utilisateur actuellement connecté et l'utilisateur en cours d'édition ont le même "StudioId". Note: Je veux utiliser AuthorizeAttribute avec plusieurs contrôleurs, pas seulement « UserController »

Alors mes questions vous êtes:

1. Que dois-je faire pour stocker « StudioId » du utilisateur courant authentifié, comme Ceci sera utilisé sur plusieurs contrôleurs.
2. Comment passer l'authentification à la couche de service, car je veux valider que les demandes sont valides dans les couches de service et d'accès aux données, pas seulement sur le client. (Si cela est conseillé, je suis juste en supposant que la validation sur le client ne suffit si je veux réutiliser le BLL et DAL plus tard dans une application autonome)

Technologies utilisées: - LINQ to SQL via le modèle Repository - ASP.NET MVC Preview 2

Des recommandations ou des exemples de code seraient les bienvenus.

Answer 1

J'ai essentiellement fait ma sécurité principalement au niveau du contrôleur pour quelque chose comme ça. J'ai pris la décision de ne pas passer les choses trop loin dans la chaîne pour savoir si une personne y avait accès ou si je le faisais, je m'assurerais simplement que IPrincipal.IsInRole() suffirait à le satisfaire.

Maintenant, j'ai fait quelque chose d'autre qui semble un peu plus hackier. Je devais m'assurer que les personnes qui étaient enregistrées et auxquelles cette pièce leur avait été assignée étaient les seules à pouvoir y accéder à partir de cette section.

Je créé un filtre d'attribut qui fonctionne comme ceci:

public override void OnActionExecuting(ActionExecutingContext filterContext) 
     { 
      var thingToView = filterContext.ActionParameters[_thingToView] as thingToView ; 
      var registration = filterContext.ActionParameters[_registration] as Registration; 


      if (!registration.CanSeeThing(thingToView)) 
      { 
       throw new RegistrationCannotViewThing(registration, thingToView); 
      } 

      base.OnActionExecuting(filterContext); 
     } 

Maintenant, la chose qui se sentait un peu hacky dans cette mise en œuvre est que je l'ai fait sur ma méthode de commande:

[AuthFilter(ThingToView ="thingToView", Registration="registration") 
public ActionResult Method(Thing thingToView, Registration registration) 
{ 
.... 
} 

Les affectations de paramètres réelles se sont produites dans le classeur de modèle. La sécurité passe par le filtre qui vérifie les paramètres transmis à la méthode. J'ai ensuite réutilisé ce filtre dans beaucoup d'endroits.

J'ai fait quelque chose de similaire avec un classeur modèle à un post Scott Hanselman ici: http://www.hanselman.com/blog/IPrincipalUserModelBinderInASPNETMVCForEasierTesting.aspx afin de passer quel utilisateur appelle une méthode. Je suppose que vous pouvez utiliser l'exemple de post de blog ci-dessus afin d'obtenir votre objet utilisateur à votre méthode de contrôleur afin de le transmettre à votre couche de service.