2010-06-16 7 views
12

Tengo una aplicación que se nutre de BeginRequestEndRequest y de configurar y derribar las sesiones de NHibernate como este:¿Cómo afecta "Require SSL" al ciclo de vida de la aplicación ASP.NET MVC?

BeginRequest += delegate 
{ 
    CurrentSessionContext.Bind(SessionFactory.OpenSession()); 
}; 

EndRequest += delegate 
{ 
    var session = CurrentSessionContext.Unbind(SessionFactory); 
    session.Dispose(); 

    Container.Release(session); 
}; 

Esto funciona bien cuando se implementa en IIS, hasta que marque la casilla "Requerir SSL". Una vez que hago esto, obtengo un NullReferenceException al session.Dispose().

No he depurado esto todavía y, sí, la solución es trivial, pero tengo curiosidad acerca de cómo "Requerir SSL" afecta el ciclo de vida de una solicitud. ¿Una sesión no está configurada en el servidor en estos casos?

EDITAR: Solo para aclarar, me refiero a la opción "Requerir SSL" en la configuración de IIS para la aplicación, no el atributo RequireHttps para los controladores.

+0

¿Está navegando inicialmente a la aplicación usando Http que le indica que use Https? O ... ¿Estás navegando directamente a la aplicación usando Https? – Jason

+1

Me estoy conectando con Http. Esperaba que IIS respondiera de inmediato con un redireccionamiento sin invocar ninguno de mis códigos. – Ragesh

Respuesta

5

Esto despertó mi curiosidad así que busqué un poco; perdón por la nigromancia.

Creé un proyecto simple que conectó las notificaciones para cada evento del ciclo de vida en el objeto de la aplicación y establecí los puntos de interrupción en cada uno.

Resulta que cuando se establece "Requerir SSL" y se accede sin SSL, la mayoría de los eventos se omiten por completo. El primer evento que se desencadena es LogRequest, seguido de PostLogRequest, EndRequest, PreSendRequestContent y PreSendRequestHeaders (en ese orden). No se disparan otros eventos.

Así que su código se bloqueaba porque el evento BeginRequest nunca se activó, y el delegado EndRequest intentó Dispose() algo que nunca se había creado.

Lo que me resulta interesante es averiguar por qué IIS se comporta así. Sospecho que la razón es que IIS aún necesita registrar intentos de conexión no válidos, así como enviar contenido y encabezados, incluso si el recurso solicitado requiere SSL. Algo tiene que generar esa página amistosa "prohibida", después de todo. Lo que no sé es por qué se llama EndRequest cuando no se molestaron en llamar al BeginRequest; Supongo que hay un código de limpieza de IIS/ASP que depende de eso.

Este comportamiento varía dependiendo de si el grupo de aplicaciones se está ejecutando en el modo "Integrado" o "Clásico". En el modo "Clásico", todos los eventos ASP.NET se activan "entre" los eventos IIS PreRequestHandlerExecute y PostRequestHandlerExecute. No dijiste cuál estabas ejecutando, pero tiene que ser integrado; de lo contrario, habrías visto el comportamiento que esperabas, es decir, ninguno de tu código se habría ejecutado en absoluto.

Curiosamente, si intenta suscribirse a los eventos LogRequest, PostLogRequest, o MapRequestHandler en el modo Clásico, obtiene una excepción de tiempo de ejecución; estos solo "tienen sentido" en el contexto de la tubería integrada.

+0

¡Gran respuesta! Gracias por tomarse el tiempo para investigar esto. – Ragesh

Cuestiones relacionadas