AllowAnonymous en ASP.NET MVC 4

Desde el principio de los tiempos, ASP.NET MVC dispone de un mecanismo muy sencillo para controlar el acceso a acciones, basado en los sistemas de autenticación por formulario estándar de ASP.NET.

A grandes rasgos, el asunto consiste en decorar acciones, o incluso los controladores completos, con el atributo [Authorize], de forma que si el usuario no ha superado el procedimiento de autenticación, no se podrá acceder a ellas. Además, gracias a los parámetros admitidos por este filtro, es posible indicar qué usuarios concretos pueden ejecutar la acción, o qué roles son los permitidos:

public class CustomersController : Controller
{
    [Authorize(Roles = "manager")]
    public ActionResult Delete(int id)
    {
        // TODO: Delete a customer
    }

    //...
}

Sin embargo, había algunos escenarios que eran algo molestos de implementar usando esta técnica. Imaginad que estáis desarrollando una web totalmente privada, en la que es necesario incluir el atributo [Authorize] a todos los controladores: el ideal sería utilizar filtros globales, ¿no? En vez de modificar cada uno de los controladores, haríamos lo siguiente en el global.asax.cs:

    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new HandleErrorAttribute());
        filters.Add(new AuthorizeAttribute());
    }

Y como casi todo en la vida, no es tan sencillo. Este atributo afectaría a las acciones que retornan las vistas del propio formulario de login, por lo que simplemente no sería posible acceder a la aplicación. Lógicamente hay varias soluciones para este problema; por ejemplo, podríamos introducir a mano el filtro en los controladores, o incluso mejor aún, crear un controlador base con el atributo y heredar de él todos los controladores menos los destinados a facilitar la identificación del usuario.

ASP.NET MVC 4 introduce un nuevo filtro, denominado [AllowAnonymous] cuya utilidad seguro que podéis deducir en este momento: aplicado a un controlador o acción, hace que se ignore en éste cualquier posible atributo [Authorize] que pudiera haberse aplicado al mismo. De hecho, en la misma plantilla de proyectos MVC 4 ya vemos que se utiliza bastante en el controlador AccountController , tradicionalmente destinado a realizar las tareas de conexión, registro y desconexión de usuarios:

    [Authorize]
    public class AccountController : Controller
    {

        //
        // GET: /Account/Login

        [AllowAnonymous]
        public ActionResult Login()
        {
            // ... 
        }
    }

Y este post podría acabar aquí, pero hay una curiosidad que quería comentar sobre la forma en que está implementado este filtro. Si observamos su código fuente, vemos que es, poco más o menos, así:

namespace System.Web.Mvc 
{  
   [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, 
                   AllowMultiple = false, Inherited = true)] 

   public sealed class AllowAnonymousAttribute : Attribute 
   { 

   } 
}

Salvo la metainformación contenida en el AttributeUsage, el resto es una clase vacía (!). Aunque al principio puede parecer raro, es muy lógico: la magia la pone el atributo [Authorize] en cuya implementación encontramos la lógica que posibilitará la ejecución de una acción si se encuentra decorada (ella o su controlador) con [AllowAnonymous], saltándose todas las comprobaciones de autorización:

bool skipAuthorization = 
    context.ActionDescriptor.IsDefined(typeof(AllowAnonymousAttribute), inherit: true)
    || context.ActionDescriptor.ControllerDescriptor.IsDefined(
                typeof(AllowAnonymousAttribute), inherit: true);

if (skipAuthorization)
{
    return; 
}

Publicado en Variable not found.