Autorisierung und ASP.NET MVC Caching

Question

Ich bin verwirrt auf ASP.NET MVC-Caching und Autorisierung und dringend um Klarstellung.

Meine selbstgemachte Genehmigung Attribut erbt von AuthorizeAttribute. Seine überschriebene AuthorizeCore Verfahren läuft jedes Mal, auch wenn ich ein [OutputCache] Attribut auf einer Controller-Aktion gesetzt. Ich verstehe, dass ein Teil.

Jetzt ist der Geist Bender für mich: AuthorizeCore wird nicht jetzt jedes Mal, wenn ich die Ausgabezwischenspeicherung tatsächlich tun und die Seite aus dem Cache bedient. Der Grund dafür ist, dass, wenn die Anforderung gecached ist, die httpContext.Session mit AuthorizeCore versorgt ist null !? Hier ist ein vereinfachter Code:

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

Also, wenn httpContext.Session null ist dies offensichtlich jedes Mal versagt. Ich brauche die Sitzung zwar zugreifen, wie sonst kann ich überprüfen, ob der Antrag berechtigt ist? Das macht keinen Sinn machen - wenn dies ist, wie es sein soll, dann würde ich nie die Lage sein, im Cache gespeicherten Seiten mit Authentifizierung in ASP.NET MVC zusammen zu verwenden. Hilfe?

Answer 1

Es gibt zwei getrennte Fragen:

1. arbeitet die Authentifizierung mit Caching in MVC?
2. Ist Session Arbeit vor der Authentifizierung in das Gesicht eines Cache (auch für nicht authentifizierte Benutzer, die noch eine hoffentlich eindeutige Session haben)?

Die Antworten sind jeweils ja und nein. Authentifizierung funktioniert mit Caching. Versuchen Sie es mit dem SQL oder Domain-Mitgliedschaft Anbieter; Sie werden sehen.

Caching kann jedoch vor dem Authentifizierungsmodul ausgeführt werden. (Für Bonuspunkte:? Warum) Die Authentifizierung wird nur aufgerufen, wenn es speziell um den Cache-Haken (wie AuthorizeAttribute der Fall ist). Da Sitzungen benutzerspezifisch sind, gibt es nicht garantieren Ihnen eine Sitzung innerhalb von AuthorizeCore haben werden.

Weitere Bonuspunkte: Wie könnte diese Änderung, wenn Sie varyByUser im Cache-Konfiguration angegeben

Leider Authentifizierung richtig zu tun ist hart, denn richtig macht jede Art von Sicherheit ist schwer. Microsoft versucht, diese einfacher mit dem Mitgliedschaftsanbieter API zu machen. Ich empfehle dringend, mit , wenn die benutzerdefinierte Authentifizierung implementieren. Ich empfehle auch die Einbau-Anbieter verwenden und sie erstrecken, anstatt sie neu zu schreiben, wann immer möglich.

Ein weiterer Punkt: Die ASP.NET-Session-Provider und die ASP.NET-Mitgliedschaft Anbieter sind vollständig getrennt. Verschiedene Mitgliedschaft Benutzer teilen können (!) Eine Sitzung, und ja , können Sie Angriff einer Website auf diese Weise. Es ist nie sichere sicherheitsrelevante Informationen in einer Sitzung zu setzen. Sicherheit ist hart.