Attribut d'autorisation MVC + HttpUnauthorizedResult + FormsAuthentication

Après avoir parcouru la section MVC sur CodePlex, j'ai remarqué que l'attribut [Authorize] dans MVC renvoie un HttpUnauthorizedResult() lorsque l'autorisation échoue (codeplex AuthorizeAttribute class).Attribut d'autorisation MVC + HttpUnauthorizedResult + FormsAuthentication

Dans la source de HttpUnauthorizedResult() de CodePlex est le code (je ne suis pas autorisé à entrer dans une autre URL que mon représentant est pas assez élevé, mais remplacer les chiffres sur l'URL ci-dessus avec 22929 # 266476):

// 401 is the HTTP status code for unauthorized access - setting this 
// will cause the active authentication module to execute its default 
// unauthorized handler 
context.HttpContext.Response.StatusCode = 401;

En particulier, le commentaire décrit le gestionnaire non autorisé par défaut du module d'authentification.

Je ne peux pas sembler trouver des informations sur ce défaut gestionnaire non autorisé. En particulier, je n'utilise pas FormsAuthentication et lorsque l'autorisation échoue, j'obtiens une page d'erreur IIS 401 moche.

Est-ce que quelqu'un sait sur ce gestionnaire par défaut non autorisé, et en particulier comment FormsAuthentication crochets se pour la remplacer?

J'écris une application très simple pour mon équipe de football qui confirment ou nient si elles peuvent jouer un match particulier. Si j'active FormsAuthentication dans web.config, la redirection fonctionne, mais je n'utilise pas FormsAuthentication et j'aimerais savoir s'il existe une solution de contournement.

Source

2010-01-26 Anthony

Quel type d'authentification utilisez-vous? – Zote

Voulez-vous autoriser du tout? Quel est le résultat final que vous recherchez en ce qui concerne l'authentification? –

J'ai écrit mon propre petit module d'authentification qui attribue une identité et des rôles. Le [Authorize] doit vérifier si l'utilisateur peut visiter la page pour confirmer qu'il peut jouer dans un match particulier. S'ils ne sont pas autorisés à jouer, en fonction d'un rôle, au lieu de donner une erreur 401 qui est assez inutile, je veux leur donner des informations plus utiles sur les raisons pour lesquelles ils ne peuvent pas jouer. Surcharger cette 401 semble la manière logique de faire ceci, mais je suis surpris de voir à quel point il ya peu de documentation sur ce gestionnaire non autorisé par défaut – Anthony

Si vous avez réflecteur, jetez un oeil à System.Web.Security.FormsAuthenticationModule.Init(). Cette méthode croise Application_EndRequest et appelle OnLeave(). La méthode OnLeave() vérifie que le code de réponse est HTTP 401. Si c'est le cas, le module effectue une redirection plutôt que de faire bouillir le 401 jusqu'au client. (Cette logique est ce que le commentaire appelle le «gestionnaire non autorisé par défaut».) Dans votre cas particulier, ASP.NET laisse la bulle 401 au client, mais IIS l'intercepte et affiche une page d'erreur laide.

Vous pouvez faire quelque chose de très similaire à l'intérieur Global.asax. Faire une méthode Application_EndRequest; cette méthode sera appelée à la fin de chaque requête desservie par votre application. De là, vous pouvez faire ce que vous voulez. Si vous voulez vérifier si la réponse est un 401 et les rediriger vers une page différente, vous pouvez le faire à partir d'ici.

Source

2010-01-26 17:46:12 Levi

Thanks Levi - Je n'ai pas vraiment utilisé Reflector mais je vais y jeter un coup d'oeil. J'aurais dû me douter que ça aurait pu être quelque chose qui se serait accroché à l'événement EndRequest, bien qu'il semble que ce soit une façon assez inhabituelle de faire la redirection. Je suppose que l'autre option serait de créer une classe d'autorisation personnalisée, qui, lorsque l'autorisation échoue appelle une méthode différente à HttpUnauthorizedResult() qui pourrait renvoyer un ActionResult différent (qui pourrait être la page d'informations d'échec d'autorisation)? – Anthony

Cela fonctionnerait. Si vous suivez cette route, sous-classe AuthorizeAttribute et remplacez la méthode HandleUnauthorizedRequest(). Le seul véritable avantage à accrocher EndRequest à cela est que l'accrochage EndRequest vous permet de piéger les échecs d'autorisation d'autres parties de l'application, pas seulement [Authorize]. – Levi

Je pense que le hooking EndRequest sonne comme une meilleure utilisation du temps car, comme vous le dites, il pourrait couvrir plus de l'application.J'ai aussi lu à propos de AuthorizeAttribute et des problèmes potentiels avec la mise en cache de sortie - il y a même un commentaire à ce sujet dans la source de codeplex, bien qu'en fait je n'aurais pas le temps de faire les deux types d'autorisation. Bien que je vais commencer par l'EndRequest. Merci pour votre aide Levi. – Anthony

Attribut d'autorisation MVC + HttpUnauthorizedResult + FormsAuthentication

Répondre

Questions connexes