Asp.net MVC4: Autoriser à la fois sur le contrôleur et l’action

Si j’ai l’atsortingbut Authorize à la fois sur le contrôleur et sur l’action, lequel prendra l’effet? Ou les deux prendront-ils effet?

    Tu as demandé:

    Si j’ai un atsortingbut Authorize sur le contrôleur et l’action, lequel prendra l’effet? Tous les deux?

    Pour répondre simplement à ceci: Les deux. L’effet est à AND les deux ressortingctions ensemble. Je vais expliquer pourquoi ci-dessous …

    Détails

    Donc, il y a quelques raisons pour lesquelles vous pourriez demander ceci.

    1. Vous voulez savoir comment appliquer une contrainte supplémentaire sur une action par rapport à une méthode. par exemple
      • Au niveau du contrôleur, appliquez les utilisateurs dans le rôle “utilisateur”
      • Au niveau de l’action, appliquez également les utilisateurs dans le rôle “admin”
    2. Vous souhaitez remplacer la contrainte de contrôleur au niveau de l’action
    3. Vous souhaitez supprimer la contrainte de contrôleur au niveau de l’action et rendre la méthode accessible aux utilisateurs anonymes

    Vous n’avez pas spécifié votre version de MVC, je suppose donc la plus récente à ce jour (MVC 4.5). Cependant, cela ne changera pas beaucoup la réponse, même si vous utilisiez MVC 3.

    [Anonymous] remplace le contrôleur [Authorize] (case 3)

    Cas n ° 3. Je n’ai pas besoin de couvrir (l’utilisation de [AllowAnonymous] ) car il a déjà été répondu partout dans le monde et sur le Web . Autant dire: si vous spécifiez [AllowAnonymous] sur une action, celle-ci sera [AllowAnonymous] publique même si le contrôleur a [Authorize] dessus.

    Vous pouvez également soumettre un site Web entier à une autorisation en utilisant un filtre global et utiliser AllowAnonymous sur les quelques actions ou contrôleurs que vous souhaitez rendre publics.

    [Authorize] est additif (cas 1)

    Le cas 1 est facile. Prenez le contrôleur suivant comme exemple:

     [Authorize(Roles="user")] public class HomeController : Controller { public ActionResult AllUsersIndex() { return View(); } [Authorize(Roles = "admin")] public ActionResult AdminUsersIndex() { return View(); } } 

    Par défaut, [Authorize(Roles="user")] met à la disposition des comptes du rôle “user” toutes les actions du contrôleur uniquement. Par conséquent, pour accéder à AllUsersIndex vous devez être dans le rôle “utilisateur”. Cependant, pour accéder à AdminUsersIndex vous devez être à la fois dans le rôle “utilisateur” et dans le rôle “admin”. Par exemple:

    • UserName: Bob, Roles: utilisateur, impossible d’ accéder à AdminUsersIndex , mais peut accéder à AllUsersIndex
    • UserName: Jane, Roles: admin, impossible d’ accéder à AdminUsersIndex ou AllUsersIndex
    • UserName: Tim, Roles: user & admin, peut accéder à AdminUsersIndex et AllUsersIndex

    Cela montre que l’atsortingbut [Authorize] est additif. Cela est également vrai pour la propriété Users de l’atsortingbut, qui peut être combinée avec des Roles pour la rendre encore plus ressortingctive.

    Ce comportement est dû à la façon dont les atsortingbuts du contrôleur et de l’action fonctionnent. Les atsortingbuts sont chaînés et appliqués dans le contrôleur de commande, puis dans l’action. Si le premier refuse l’autorisation, alors le contrôle retourne et l’atsortingbut de l’action n’est pas appelé. Si le premier passe l’autorisation, le second est alors vérifié également. Vous pouvez remplacer cet ordre en spécifiant Order (par exemple, [Authorize(Roles = "user", Order = 2)] ).

    Remplacer [Authorize] (cas 2)

    Le cas 2 est plus compliqué. Rappelez ci-dessus que les atsortingbuts [Authorize] sont examinés dans l’ordre (Global puis) ​​Controller puis Action. Le premier à détecter que l’utilisateur n’est pas autorisé à être autorisé gagne, les autres ne sont pas appelés.

    Une solution consiste à définir deux nouveaux atsortingbuts comme ci-dessous. Le [OverrideAuthorize] ne fait que reporter à [Authorize] ; son seul but est de définir un type que nous pouvons vérifier. Le [DefaultAuthorize] nous permet de vérifier si l’action appelée dans la requête est décorée avec un [OverrideAuthorize] . Si c’est le cas, nous nous reportons à la vérification d’autorisation d’action, sinon nous procédons à la vérification du niveau du contrôleur.

     public class DefaultAuthorizeAtsortingbute : AuthorizeAtsortingbute { public override void OnAuthorization(AuthorizationContext filterContext) { var action = filterContext.ActionDescriptor; if (action.IsDefined(typeof(OverrideAuthorizeAtsortingbute), true)) return; base.OnAuthorization(filterContext); } } public class OverrideAuthorizeAtsortingbute : AuthorizeAtsortingbute { public override void OnAuthorization(AuthorizationContext filterContext) { base.OnAuthorization(filterContext); } } 

    Nous pouvons alors l’utiliser comme ceci:

     [DefaultAuthorize(Roles="user")] public class HomeController : Controller { // Available to accounts in the "user" role public ActionResult AllUsersIndex() { return View(); } // Available only to accounts both in the "user" and "admin" role [Authorize(Roles = "admin")] public ActionResult AdminUsersIndex() { return View(); } // Available to accounts in the "superuser" role even if not in "user" role [OverrideAuthorize(Roles = "superuser")] public ActionResult SuperusersIndex() { return View(); } } 

    Dans l’exemple ci-dessus, SuperusersIndex est disponible pour un compte ayant le rôle “superutilisateur”, même s’il ne possède pas le rôle “utilisateur”.

    Je voudrais append quelque chose à la dérogation [autoriser] (cas 2)

    OverrideAuthorizeAtsortingbute et DefaultAuthorizeAtsortingbute fonctionnent correctement, mais je découvre que vous pouvez également utiliser OverrideAuthorizationAtsortingbute qui remplace les filtres d’autorisation définis à un niveau supérieur.

     [Authorize(Roles="user")] public class HomeController : Controller { // Available to accounts in the "user" role public ActionResult AllUsersIndex() { return View(); } // Available only to accounts both in the "user" and "admin" role [Authorize(Roles = "admin")] public ActionResult AdminUsersIndex() { return View(); } // Available to accounts in the "superuser" role even if not in "user" role [OverrideAuthorization()] [Authorize(Roles = "superuser")] public ActionResult SuperusersIndex() { return View(); } } 

    Si vous l’utilisez sur le contrôleur, toutes les méthodes de ce contrôleur seront effectuées.

     [Authorize] public class SomeController(){ // all actions are effected public ActionResult Action1 public ActionResult Action2 

    Si vous souhaitez empêcher l’une de ces actions, vous pouvez utiliser quelque chose comme ceci:

     [Authorize] public class SomeController(){ // all actions are effected public ActionResult Action1 public ActionResult Action2 [AllowAnonymous] public ActionResult Action3 // only this method is not effected...