asp.net-mvc-3 - update - mvc 4+

Autorizar atributo en ASP.NET MVC

Question

Me está costando entender el uso real del atributo [Authorize] en ASP.NET MVC. Según el concepto, si decoramos un método de controlador con el atributo [Authorize] , solo los usuarios autenticados pueden acceder a los controladores.

Desarrollé una aplicación ASP.NET MVC sin decorar controladores con el atributo [Authorize] . Lo que he observado es que si implemento el mecanismo de autenticación correctamente en mi aplicación usando web.config o de alguna otra forma, no puedo acceder a la URL {controller}/{action}/{id} de un método de acción en particular.

El sistema siempre solicita iniciar sesión. Eso significa que mis controladores están seguros. Mi pregunta es la siguiente: cuando puedo asegurar mis controladores sin usar el atributo [Authorize] , ¿cuál es la necesidad real de ello?

Answer 1

El poder real viene con la comprensión y la implementación del proveedor de membresía junto con el proveedor de roles. Puede asignar usuarios a roles y de acuerdo con esa restricción puede aplicar diferentes roles de acceso para diferentes usuarios a acciones de controlador o controlador.

 [Authorize(Users = "Betty, Johnny")]
 public ActionResult SpecificUserOnly()
 {
     return View();
 }

o puedes restringir de acuerdo al grupo

[Authorize(Roles = "Admin, Super User")]
public ActionResult AdministratorsOnly()
{
    return View();
}

Answer 2

El uso de atributos [Authorize] puede ayudar a prevenir agujeros de seguridad en su aplicación. La forma en que MVC maneja las URL (es decir, enrutarlas a un controlador en lugar de a un archivo real) hace que sea difícil proteger todo a través del archivo web.config.

Lea más aquí: http://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx

Answer 3

Existe porque es más conveniente de usar, también es una ideología completamente diferente que usa atributos para marcar los parámetros de autorización en lugar de la configuración xml. No pretendía vencer la configuración de propósito general ni ningún otro marco de autorización, solo la forma de hacerlo de MVC. Estoy diciendo esto, porque parece que estás buscando una característica técnica con ventajas que probablemente no sean ... simplemente una excelente conveniencia.

BobRock ya enumeró las ventajas. Solo para agregar a su respuesta, otros escenarios son que puede aplicar este atributo a todo el controlador, no solo a las acciones, también puede agregar diferentes parámetros de autorización de roles a diferentes acciones en el mismo controlador para mezclar y combinar.

Answer 4

Una ventaja es que está compilando el acceso a la aplicación, por lo que no puede ser modificado accidentalmente por alguien que modifique el Web.config.

Esto puede no ser una ventaja para usted, y podría ser una desventaja. Pero para algunos tipos de acceso, puede ser preferible.

Además, encuentro que la información de autorización en Web.config lo contamina y hace que sea más difícil encontrar cosas. Entonces, de alguna manera es su preferencia, en otros no hay otra manera de hacerlo.

Answer 5

Usar el atributo Authorize parece más conveniente y se siente más como ''MVC way''. En cuanto a las ventajas técnicas, hay algunas.

Un escenario que me viene a la mente es cuando estás usando el almacenamiento en caché de resultados en tu aplicación. Autorizar el atributo maneja bien.

Otro sería extensibilidad. El atributo Authorize es solo un filtro básico, pero puede anular sus métodos y realizar algunas acciones de preautorización, como el registro, etc. No estoy seguro de cómo lo haría a través de la configuración.