Autorización y almacenamiento en caché MVC de ASP.NET

Question

Estoy confundido sobre el almacenamiento en caché y la autorización ASP.NET MVC y necesito una aclaración urgente.

Mi atributo de autorización hecho a sí mismo hereda de AuthorizeAttribute . Su método AuthorizeCore anulado se ejecuta siempre, incluso si configuro un atributo [OutputCache] en una acción del controlador. Entiendo esa parte.

Ahora la mente me dobla: AuthorizeCore fallará cada vez que realizo el almacenamiento en caché de salida y la página se sirve desde el caché. La razón es que cuando la solicitud se almacena en caché, la httpContext.Session suministrada con AuthorizeCore es null !? Aquí hay un código simplificado:

protected override bool AuthorizeCore(HttpContextBase httpContext) {
    return (Session["userId"] != null)
}

Entonces, si httpContext.Session es nulo , esto obviamente falla cada vez. Sin embargo, necesito acceder a la sesión, ¿de qué otra manera puedo verificar si la solicitud está autorizada? Esto no tiene ningún sentido: si así es como debería ser, entonces nunca podría usar páginas en caché junto con autenticación en ASP.NET MVC. Ayuda?

Answer 1

Hay dos preguntas separadas:

1. ¿La autenticación funciona con el almacenamiento en caché en MVC?
2. ¿La sesión funciona antes de la autenticación frente a un caché (incluso para usuarios no autenticados, que todavía tienen una sesión única)?

Las respuestas, respectivamente, son sí y no. La autenticación funciona bien con el almacenamiento en caché. Pruébelo con los proveedores de membresía de SQL o dominio; ya verás.

Sin embargo, el almacenamiento en caché puede ejecutarse antes del módulo de autenticación. (Para puntos de bonificación: ¿Por qué?) La autenticación se llama solo si engancha específicamente el caché (como lo hace AuthorizeAttribute). Debido a que las sesiones son específicas del usuario, no garantiza que tendrá una sesión dentro de AuthorizeCore.

Más puntos de bonificación: ¿Cómo podría cambiar esto si especificas varyByUser en tu configuración de caché?

Desafortunadamente, hacer la autenticación correcta es difícil, porque hacer cualquier tipo de derecho de seguridad es difícil. Microsoft intenta hacer esto más fácil con la API del proveedor de membresía. Recomiendo encarecidamente usar eso al implementar la autenticación personalizada. También recomiendo usar los proveedores integrados y extenderlos en lugar de reescribirlos siempre que sea posible.

Otro punto: el proveedor de sesión ASP.NET y el proveedor de membresía ASP.NET están completamente separados. Los diferentes usuarios de membresía pueden compartir (!) Una sesión y sí , puede atacan un sitio de esta manera. Es nunca seguro poner información relacionada con la seguridad en una sesión. La seguridad es difícil.