Je me suis demandé si / comment je peux remplacer le comportement [Autoriser] par défaut dans ASP.NET MVC. Je sais que je peux créer un nouveau filtre d'action, faire mon propre attribut, etc. Je suis simplement intéressé si je peux simplement modifier le comportement [Autoriser] et remplacer son fonctionnement avec mon propre code? P>
EDIT STRUT>: Les gars et les filles. J'apprécie votre contribution mais comme je l'ai écrit, je suis
5 Réponses :
Vous pouvez sous-classer le filtre AutorizeAttribute et mettre votre propre logique à l'intérieur.
Voyons un exemple. Disons que vous souhaitez toujours autoriser les connexions locales. Cependant, s'il s'agit d'une connexion distante, vous souhaitez conserver la logique d'autorisation habituelle. P>
Vous pouvez faire quelque chose comme: p> ou vous pouviez Autoriser toujours une certaine adresse distante (votre machine, par exemple). P> C'est ça! P> Edit: oublié de mentionner, vous l'utiliserez de la même manière que vous utiliseriez le filtre AuthorizEattribute : p>
Je ne vois que de 2 façons: Remplacer 1) Très facile: P> Autorizeattribute.AnaThorization Code> Méthode ou créant votre propre attribut Autoriser à partir de zéro.
public class CustomAuthorizeAttribute : AuthorizeAttribute
{
public override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
/// your behavior here
}
}
Vous devriez éviter de créer un attribut d'autorisation à partir de zéro si vous ne voulez pas de mal à la tête lorsque vous implémenterez la mise en cache ... L'attribut Authorize de ASP.NET MVC traite déjà de cet aspect.
Oui, jetez un coup d'œil aux documents MSDN pour Autorizeattribute: http://msdn.microsoft.com/en-us/library/system.web.mvc.authorizeattribute.aspx . P>
Fondamentalement, vous pouvez remplacer la méthode onautorization () et personnaliser le comportement. Il existe également d'autres méthodes virtuelles sur l'attribut. P>
Edit: Comme Bruno l'a souligné, vous pouvez remplacer la méthode AuthoriZecore (). La principale différence étant que Authorizecore () prend une httpcontextbasebase, tandis que l'onAuthorization () prend une autorisationContext. Une instance d'autorisationContext vous fournit plus d'informations, telles que le contrôleur, la demandeContext et le roudata. Il vous permet également de spécifier une actionResulte. P>
AUTORIZECORE () est plus restreint dans les informations que vous pouvez accéder ainsi que le résultat que vous pouvez revenir, mais si vous devez autoriser des données en cache, votre logique doit gérer le cas où vous n'avez pas de ce que Données supplémentaires (car les données sont servies à partir du cache avant que la demande ne soit acheminée via le pipeline MVC). P>
Comme toujours, vous devez comprendre votre scénario et les outils disponibles et les compromis entre eux. P>
L'AuthorizeAretribute ne contient pas de méthode onautorize. Voulez-vous dire sur l'onautoriation ()? Quoi qu'il en soit, vous ne devriez pas le changer, à moins que vous ne souhaitiez de mal à la tête lors de la mise en oeuvre de la mise en cache, car il s'agit d'une méthode (onauthorization) qui y traite.
Il semble que vous puissiez implémenter un filtre personnalisé comme d'habitude (et hériter autorisateur si vous le souhaitez), puis créez une nouvelle actionVoker qui hérite ControllerActionInvoker et remplace GetFilters. Dans GetFilters, vous appelez Un autre moyen potentiel est d'implémenter des fournisseurs personnalisés et des fournisseurs de rôle, en fonction de ce que vous essayez de faire. P> base.getfilters () code> Pour obtenir la liste des filtres, iTERIER via l'autorisationFilters et remplacer les appels à AutherizeFilter avec les appels à votre filtre personnalisé. P>
Pourquoi n'aurait-il pas besoin d'une action personnalisée pour un filtre d'autorisation simple?
@Bruno: Parce qu'il ne semble pas y avoir d'autre moyen de remplacer un filtre-cadre sans être propre, juste pour en créer de nouveaux.
Mais ... pourquoi voudrait-on remplacer i> le filtre-cadre? Regardez mon commentaire à la question. C'est une chose muette à faire.
@Bruno: dites que vous avez un groupe de contrôleurs déjà écrits d'un autre projet / développeur / quoi que vous ne souhaitais pas ou que vous ne puissiez pas changer pour ne pas avoir le code source. Vous ne voulez pas utiliser SQL Server pour stocker les données utilisateur et rôle, mais quelque chose d'autre. Et vous préféreriez ne pas mettre en œuvre les fournisseurs d'adhésion et de rôle personnalisés, car ils sont gonflés et que vous êtes paresseux. C'est quand! Il est probablement préférable de créer des fournisseurs personnalisés ou de créer des attributs personnalisés (nouveaux), mais il peut y avoir des situations qui appellent à remplacer les appels à l'autorisationFilter.
@svinto Pouvez-vous montrer un exemple de remplacement de l'autorisationfilter?
Implémentez votre propre fournisseur de rôle et définissez votre application pour l'utiliser. Ensuite, l'attribut Authorize respectera votre code d'athoration. P>
Pourquoi voudriez-vous conserver le nom "Autoriser" de l'attribut et modifier son comportement? C'est une mauvaise chose à faire. Les gens, quand ils voient [Autoriser] Ils s'attendent à ce que ça va faire. Si vous le changez, la lecture de votre code sera beaucoup plus difficile. Même pour vous à l'avenir.
Je ne suis pas d'accord; Si vous soutiendrez cela, tout opérateur ou méthode surcharge / primordial serait faux.
@ALEX: Je suis en désaccord. La surcharge de l'opérateur est une bonne chose. C'est une mauvaise chose à abuser de cela. L'exemple habituel: vous avez une classe de vecteur, vous créez l'opérateur "+". C'est évident ce que ça va faire. Mais qu'en est-il de l'opérateur "*"? C'est une mauvaise chose à faire, c'est un produit croisé ou un produit de points? Ou un autre type de produit personnalisé? Donc: la surcharge est bonne, mais c'est très mauvais lorsque vous masquez des conventions.
Ne pas être un expert, j'ai suivi la suggestion "Bruno Reis" de l'utiliser comme un attribut distinct [myCompanyNameAuthorize]. Un exemple de comment faire est à geekswithblogs.net/thomasthecece/archive / 2009/06/25 / ...