Wie wirkt sich "SSL erforderlich" auf den ASP.NET MVC-Anwendungslebenszyklus aus?

Ich habe eine Anwendung, die in BeginRequest und EndRequest tippt einzurichten und abzureißen NHibernate Sitzungen wie folgt aus:Wie wirkt sich "SSL erforderlich" auf den ASP.NET MVC-Anwendungslebenszyklus aus?

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

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

    Container.Release(session); 
};

Dies funktioniert gut, wenn in IIS im Einsatz, bis ich überprüfen Sie die „SSL erforderlich“ -Box. Sobald ich das mache, bekomme ich eine NullReferenceException bei session.Dispose().

Ich habe das noch nicht debugged und, ja, die Behebung ist trivial, aber ich bin nur neugierig darauf, wie "Require SSL" den Lebenszyklus einer Anfrage beeinflusst. Ist in diesen Fällen keine Sitzung auf dem Server eingerichtet?

BEARBEITEN: Nur um zu verdeutlichen, ich verweise auf die Option "Require SSL" in IIS-Konfiguration für die Anwendung, nicht das RequireHttps Attribut für Controller.

Quelle

2010-06-16 Ragesh

Navigieren Sie zunächst zu der Anwendung mit Http, die Ihnen dann sagt, dass Sie Https verwenden? Oder ... Stöberst du direkt mit Https zur App? – Jason

Ich verbinde mich mit Http. Ich habe erwartet, dass IIS sofort mit einer Weiterleitung reagiert, ohne irgendeinen Code aufzurufen. – Ragesh

Dieser pikante meine Neugierde, also grub ich mich ein wenig ein; Entschuldigung für die Nekromantie.

Ich habe ein einfaches Projekt erstellt, das Benachrichtigungen für jedes Lebenszyklusereignis auf dem Anwendungsobjekt verdrahtete und Haltepunkte für jedes Ereignis festlegte.

Es stellt sich heraus, dass wenn "Require SSL" festgelegt ist und Sie ohne SSL zugreifen, die meisten Ereignisse vollständig übersprungen werden. Das erste auslösende Ereignis ist LogRequest, gefolgt von PostLogRequest, EndRequest, und PreSendRequestHeaders (in dieser Reihenfolge). Keine anderen Ereignisse werden ausgelöst.

So stürzte Ihr Code, weil das BeginRequest Ereignis wurde nie ausgelöst, und die EndRequest Delegierten versucht, Dispose() etwas, das noch nie erstellt wurde.

Was ist interessant für mich herauszufinden, warum IIS verhält sich so. Ich vermute, der Grund ist, dass IIS weiterhin ungültige Verbindungsversuche protokollieren muss, sowie Inhalte und Header senden muss, selbst wenn die angeforderte Ressource SSL erfordert. Irgendetwas muss diese freundliche "verbotene" Seite erzeugen. Was ich nicht weiß ist, warum EndRequest überhaupt angerufen wird, wenn sie nicht anrufen BeginRequest anrufen; Ich vermute, es gibt einige IIS/ASP Cleanup-Code, der davon abhängt.

Dieses Verhalten hängt davon ab, ob der Anwendungspool im Modus "Integriert" oder "Klassisch" ausgeführt wird. Im "klassischen" Modus feuern die ASP.NET-Ereignisse alle zwischen den Ereignissen IIS PreRequestHandlerExecute und PostRequestHandlerExecute. Du hast nicht gesagt, dass du gerade liegst, aber es muss integriert sein; andernfalls hätten Sie das Verhalten gesehen, das Sie erwartet haben, d. h. keiner Ihrer Code hätte überhaupt ausgeführt.

Interessanterweise, wenn Sie versuchen, die LogRequest, PostLogRequest oder MapRequestHandler Ereignisse im klassischen Modus abonnieren, erhalten Sie eine Laufzeitausnahme; Diese sind im Kontext der integrierten Pipeline nur "sinnvoll".

Quelle

2011-03-13 21:29:36

Große Antwort! Danke, dass Sie sich die Zeit genommen haben, dies zu recherchieren. – Ragesh