2010-01-26 17 views
7

Después de examinar la sección MVC en CodePlex noté que el atributo [Authorize] en MVC devuelve un HttpUnauthorizedResult() cuando la autorización falla (codeplex AuthorizeAttribute class).MVC Authorize Attribute + HttpUnauthorizedResult + FormsAuthentication

En la fuente de HttpUnauthorizedResult() de CodePlex es el código (no puedo ingresar otra URL porque mi representante no es lo suficientemente alto, pero reemplace los números en la URL anterior con 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 particular, el comentario describe el controlador desautorizado predeterminado del módulo de autenticación.

No puedo encontrar ninguna información sobre este controlador no autorizado predeterminado. En particular, no estoy usando FormsAuthentication y cuando la autorización falla recibo una fea página de error IIS 401.

¿Alguien sabe acerca de este manejador no autorizado predeterminado y, en particular, cómo FormsAuthentication se engancha para anularlo?

Estoy escribiendo una aplicación muy simple para mi equipo de fútbol que confirma o niega si pueden jugar un partido en particular. Si habilito FormsAuthentication en el web.config, el redireccionamiento funciona, pero no estoy usando FormsAuthentication y me gustaría saber si hay una solución.

+0

¿Qué tipo de autenticación estás usando? – Zote

+0

¿Quiere autorizar? ¿Cuál es el resultado final que buscas con respecto a la autenticación? –

+1

Escribí mi propio pequeño módulo de autenticación que asigna una identidad y funciones. El [Autorizar] necesita verificar si el usuario puede visitar la página para confirmar que puede jugar en una partida en particular. Si no se les permite jugar, en función de un rol, en lugar de dar un error 401 que es bastante inútil, quiero darles más información utilizable sobre por qué no pueden jugar. Anular este 401 parece ser la forma lógica de hacerlo, pero me sorprende la poca documentación que hay sobre este controlador no autorizado predeterminado – Anthony

Respuesta

11

Si tiene Reflector, eche un vistazo a System.Web.Security.FormsAuthenticationModule.Init(). Este método enlaza Application_EndRequest y llama a OnLeave(). El método OnLeave() comprueba que el código de respuesta sea HTTP 401. Si es así, el módulo realiza una redirección en lugar de burbujear el 401 hasta el cliente. (Esta lógica es a lo que el comentario se refiere como el "manejador no autorizado predeterminado"). En su caso particular, ASP.NET está dejando que el 401 salte al cliente, pero IIS lo está interceptando y mostrando una página de error fea.

Puede hacer algo muy similar desde Global.asax. Cree un método Application_EndRequest; este método se llamará al final de cada solicitud atendida por su aplicación. Desde aquí, puedes hacer lo que quieras. Si desea verificar si la respuesta es un 401 y redirigirlos a una página diferente, puede hacerlo desde aquí.

+0

Gracias Levi - Realmente no he usado Reflector, pero lo echaré un vistazo. Debería haber sospechado que podría haber sido algo que se enganchara al evento EndRequest, aunque parece una forma bastante desagradable de hacer el redireccionamiento. Supongo que la otra opción sería crear una clase de autorización personalizada, que cuando falla la autorización llama a un método diferente a HttpUnauthorizedResult() que podría devolver un ActionResult diferente (¿cuál podría ser la página de información de error de autorización? – Anthony

+1

Eso funcionaría. Si sigue esta ruta, subclass AuthorizeAttribute y anule el método HandleUnauthorizedRequest(). El único beneficio real de enganchar EndRequest sobre esto es que conectar EndRequest le permite interceptar fallas de autorización de otras partes de la aplicación, no solo de [Authorize]. – Levi

+0

Creo que conectar EndRequest suena como un mejor uso del tiempo porque, como dices, podría abarcar más de la aplicación.También he leído sobre AuthorizeAttribute y posibles problemas con el almacenamiento en caché de resultados; incluso hay un comentario al respecto en la fuente codeplex, aunque en realidad si tengo el tiempo creo que no estaría de más hacer ambos tipos de autorización. Aunque comenzaré con EndRequest. Gracias por tu ayuda, Levi. – Anthony

Cuestiones relacionadas