Warum sind auf Websites in IIS7 / 7.5 standardmäßig ASP.NET ISAPI-Filter aktiviert?

EDIT: Aufgrund der potenziell kritischen Charakter der Antworten auf einige meiner Fragen unten, Ich füge diese starke Warnung: Verwenden Sie nicht entfernen Sie die Filter , die ich von hier sprechen , wenn Sie genau wissen , was es tut; Die Sicherheit Ihrer Anwendung kann gefährdet sein.

Ich habe gerade festgestellt, dass auf einem neuen Win 2008R2-Server, den ich für die Verwendung mit IIS7.5 konfiguriere, die ISAPI-Filter für ASP.NET standardmäßig in der Stammkonfiguration und daher auf allen Sites aktiviert sind. Ich habe auch einen 2008- und einen 2008R2-Server überprüft, auf die ich Zugriff habe, und diese haben auch dasselbe. ASP.NET ISAPI-Filter

Nach meinem Verständnis werden diese nur benötigt, wenn eine Web-App im klassischen Modus ausgeführt wird. Meine Apps werden alle im integrierten Modus ausgeführt. Ich habe alle ASP.NET-bezogenen Filter von einer ASP.NET-Site entfernt, die ich auf den neuen Server verschiebe, und es scheint kein Problem mit der App verursacht zu haben.

In der Tat, es ist ein Problem verursachen , bevor ich den 32-Bit - v4 Eintrag auf einer v2 App entfernt. Aber dann habe ich sie alle entfernt, weil ich nicht glaube, dass sie überhaupt gebraucht werden.

Meine Hauptfrage: Ist der einzige Grund, warum diese standardmäßig in der Root-Konfiguration enthalten sind, um Apps im klassischen Modus zu unterstützen, für deren Ausführung sie erforderlich wären?

Sekundäre Frage: Sollte ich sie nicht auf allen Sites entfernen, die im integrierten Modus arbeiten, unter der Annahme, dass sie zumindest nichts tun und im schlimmsten Fall Ressourcen verbrauchen, indem sie vorhanden sind (oder noch schlimmer, die Anforderungen tatsächlich bearbeiten!)?

Bonusfrage: Denken Sie, wenn ich mein Dateiberechtigungsschema für die Inhaltsverzeichnisse der Website auf diesen beiden vorherigen Servern jetzt erneut überprüfe, werde ich überrascht sein oder einige Änderungen bemerken, wenn ich nur das oben Gesagte herausfinde?

Bearbeiten: Beachten Sie, dass es wahrscheinlich gefährlich ist , die Einträge aspnet_filter.dll für ISAPI-Filter zu entfernen. Der Eintrag im IsapiFilterModule unter der folgenden Seiten-URL weist darauf hin, dass das Filtern von geschützten Inhalten über diesen Filter erfolgt. Zum Beispiel; .config .csund .vbDateien. http://learn.iis.net/page.aspx/121/iis-7-modules-overview/

— Andrew Barber
quelle

Das habe ich ursprünglich auch gedacht, aber nein - es gibt tatsächlich einige Funktionen, die der Filter in beiden Modi bietet - zum Beispiel die Unterstützung von Cookieless-Sitzungen.

Trennen Sie das Verhalten des ISAPI-Filters vom Verhalten der ISAPI-Erweiterung - die Erweiterung ist das, was der integrierte Modus beseitigt.

— TristanK
quelle

Ich habe diese Antwort akzeptiert. Ich trete mich ins Heck, weil ich nicht zwischen der ISAPI-Erweiterung (die im integrierten Modus nicht existieren sollte) und dem Filter - der sollte - nicht unterschieden habe. Es bietet nicht nur Unterstützung für Cookieless-Sitzungen, sondern auch das Filtern geschützter URLs. Wenn Sie also den Filter der entsprechenden Version entfernen, kann eine App wahrscheinlich unbeabsichtigte URLs bereitstellen, was eine sehr schlechte Idee ist!

— Andrew Barber