ASP.NET MVC Personnalisé Autorisation

J'ai une question à propos de la coutume de l'autorisation dans la MVC.

J'ai un site que je veux limiter l'accès à certaines pages, en fonction de leur appartenance à un groupe. Maintenant, j'ai vu des tonnes d'exemples sur la façon de le faire que si il y a un seul groupe admin et un seul groupe d'utilisateurs, par exemple, mais pas des exemples à un troisième niveau.

Par exemple, seuls les utilisateurs de l'entreprise peut afficher les commandes de leur propre entreprise (et chaque société a ses propres administrateurs, etc). Ces sociétés sont stockées dans une base de données. Donc, j'ai vu des façons de le faire personnalisé autorisation, en remplaçant le AuthorizeCore méthode sur la AuthorizeAttribute, mais je ne sais pas comment accéder aux paramètres passés dans la manette pour voir si l'utilisateur a accès à la commande (numéro de commande, par exemple).

Est-ce vraiment le meilleur endroit pour faire le chèque, ou ce devrait juste être traitées directement à partir de la méthode du contrôleur?

InformationsquelleAutor doobist | 2009-06-09
  1. 30

    La AuthorizationContext (paramètre OnAuthorize) permet d'accéder au Contrôleur, RouteData, HttpContext, etc. Vous devriez être en mesure de les utiliser dans une coutume d'autorisation de filtre pour faire ce que vous voulez. Ci-dessous un exemple de code à partir d'un RoleOrOwnerAttribute dérivé de AuthorizeAttribute.

    public override void OnAuthorization( AuthorizationContext filterContext )
{
if (filterContext == null)
{
throw new ArgumentNullException( "filterContext" );
}
if (AuthorizeCore( filterContext.HttpContext )) //checks roles/users
{
SetCachePolicy( filterContext );
}
else if (!filterContext.HttpContext.User.Identity.IsAuthenticated)
{
//auth failed, redirect to login page
filterContext.Result = new HttpUnauthorizedResult();
}
//custom check for global role or ownership
else if (filterContext.HttpContext.User.IsInRole( "SuperUser" ) || IsOwner( filterContext ))
{
SetCachePolicy( filterContext );
}
else
{
ViewDataDictionary viewData = new ViewDataDictionary();
viewData.Add( "Message", "You do not have sufficient privileges for this operation." );
filterContext.Result = new ViewResult { MasterName = this.MasterName, ViewName = this.ViewName, ViewData = viewData };
}
}
//helper method to determine ownership, uses factory to get data context,
//then check the specified route parameter (property on the attribute)
//corresponds to the id of the current user in the database.
private bool IsOwner( AuthorizationContext filterContext )
{
using (IAuditableDataContextWrapper dc = this.ContextFactory.GetDataContextWrapper())
{
int id = -1;
if (filterContext.RouteData.Values.ContainsKey( this.RouteParameter ))
{
id = Convert.ToInt32( filterContext.RouteData.Values[this.RouteParameter] );
}
string userName = filterContext.HttpContext.User.Identity.Name;
return dc.Table<Participant>().Where( p => p.UserName == userName && p.ParticipantID == id ).Any();
}
}
protected void SetCachePolicy( AuthorizationContext filterContext )
{
//** IMPORTANT **
//Since we're performing authorization at the action level, the authorization code runs
//after the output caching module. In the worst case this could allow an authorized user
//to cause the page to be cached, then an unauthorized user would later be served the
//cached page. We work around this by telling proxies not to cache the sensitive page,
//then we hook our custom authorization code into the caching mechanism so that we have
//the final say on whether a page should be served from the cache.
HttpCachePolicyBase cachePolicy = filterContext.HttpContext.Response.Cache;
cachePolicy.SetProxyMaxAge( new TimeSpan( 0 ) );
cachePolicy.AddValidationCallback( CacheValidateHandler, null /* data */);
}
    • Merci, c'est ce que je cherchais. Qu'est-ce que le SetCachePolicy méthode?
    • J'ai refait le code de AuthorizeFilter qui définit la politique de mise en cache de la page afin que les utilisateurs non autorisés ne pas obtenir la page servi de cache. Je vais ajouter ce morceau de code.
    • C'est génial, merci tvanfosson!
    • Dans le SetCachePolicy, ça ne serait pas une bonne idée de montrer à un CacheValidateHandler qui s'attend à "l'original" AuthorizationContext pour s'assurer que le propriétaire-case est évalué à nouveau avant d'autoriser la mise en cache des réponses?
    • il hérite du comportement de la AuthorizeAttribute de sorte qu'il ne retournera la mise en cache des réponses si vous êtes autorisé comme un utilisateur ou un rôle. Si vous avez accès par l'intermédiaire de votre association, vous ne jamais obtenir une réponse en cache. Il pourrait sans doute être plus intelligent à ce sujet, mais les principaux utilisateurs de l'autorisation pages protégées sont les admins. Je vais voir ce que je peux travailler jusqu'à permettre la mise en cache des réponses pour les personnes qui obtiennent l'accès par l'intermédiaire de "propriété".
    • aussi, il est important de ne pas utiliser le contexte de la demande précédente (depuis que l'on a autorisé). Nous avons besoin d'autoriser à nouveau cette demande en utilisant le même mécanisme, mais la nouvelle demande de données.
    • Comment pouvez-vous l'unité de test qui?
    • J'ai créer un FakeController (dérivant de Contrôleur), puis un ControllerContext pour que convenable se moque de HttpContext, l'utilisateur actuel (WindowsPrincipal), et HttpCachePolicyBase. Vous pouvez facilement simuler un ActionDescriptor. Avec le ActionDescriptor et la ControllerContext (avec accompagnateur se moque de), vous pouvez créer un AuthorizationContext de passer à OnAuthorization. Après l'appel de juste s'assurer que vos attentes sont satisfaites, et toutes les modifications pour le contexte, ont été réalisés.
    • Merci pour cette réponse, je pense que ça m'a dirigé dans la bonne direction. J'ai essayé de venir avec ma propre version, mais je ne peux pas savoir où obtenir de l'accès à ce.RouteParameter. Est-ce quelque chose que vous avez ajouté?
    • oui, c'est une propriété de l'attribut qui permet de spécifier le nom du paramètre à inspecter.

    InformationsquelleAutor tvanfosson
  2. 2

    Si l'autorisation est vraiment dynamique, je voudrais y faire face dans le contrôleur. J'ai une action où je le faire - vous pouvez revenir à une HttpUnauthorizedResult pour rediriger vers la page de connexion, ou vous pouvez afficher un message d'erreur personnalisé de votre point de vue.

    Je n'ai pas la redirection par défaut à la page de connexion lorsque quelqu'un est déjà connecté, mais pas dans le bon rôle. C'est très déroutant pour l'utilisateur.

    • Vous pourriez faire la même chose dans un attribut, qui peut être facilement appliquée par la décoration sur d'autres méthodes qui en ont besoin.
    • Oui, mais vous devez interroger le modèle de toute façon dans le contrôleur (généralement). Si vous le faites dans l'attribut, vous devez interroger le modèle deux fois, sauf si vous avez un astucieux mécanisme de mise en cache
    InformationsquelleAutor chris166
  3. 1

    Ma réponse n'est pas très grande, parce qu'il tue les tests unitaires, mais je suis en tirant les valeurs de System.Web.HttpContext.Current.Session. Le singleton est disponible tout au long du projet. En économisant de l'utilisateur en cours de session, vous pouvez y accéder à partir de n'importe où, y compris les classes utilitaires comme AuthorizeAttribute.

    Je serais ravi de voir une unité-testable solution.

    • La Session est sous-estimée.
    InformationsquelleAutor Jarrett Meyer