Wie kann ich statische Dateien mit ASP.NET-Formularauthentifizierung in IIS 7.5 schützen?

Ich habe eine Website auf einem IIS 7.5-Server mit ASP.NET 4.0 auf einem freigegebenen Host, aber in voller Vertrauen.

Die Site ist ein grundlegender “Dateibrowser”, der es den Besuchern ermöglicht, sich anzumelden und eine Liste von Dateien, die ihnen zur Verfügung stehen, anzuzeigen und natürlich die Dateien herunterzuladen. Die statischen Dateien (meist PDF-Dateien) befinden sich in einem Unterordner namens Daten auf der Website, zB http://example.com/data/ …

Die Website verwendet die ASP.NET-Formularauthentifizierung.

Meine Frage ist: Wie bekomme ich die ASP.NET-Engine, um die Anforderungen für die statischen Dateien im Datenordner zu behandeln, so dass die Anforderung von Dateien von ASP.NET authentifiziert wird und Benutzer nicht in der Lage sind, eine Verknüpfung zu einer Datei und Grab-Dateien, die sie nicht haben dürfen?

Mit freundlichen Grüßen, Egil.

Solutions Collecting From Web of "Wie kann ich statische Dateien mit ASP.NET-Formularauthentifizierung in IIS 7.5 schützen?"

Wenn der Anwendungspool im integrierten Modus ausgeführt wird, können Sie Folgendes tun.

Fügen Sie Ihrer Web.config auf oberster Ebene Folgendes hinzu.

         

Jetzt können Sie die ASP.NET-Standardberechtigungen in Ihrer web.config verwenden, um die Formularauthentifizierung für alle Dateien im Verzeichnis zu erzwingen.

       

Ich hatte das gleiche Problem mit Rollen zu authentifizieren. Durch Versuch und Irrtum habe ich es schließlich mit einer kleinen Änderung an @Joel Cunninghams Code arbeiten lassen:

  

Ich habe diese beiden Seiten als Referenzen verwendet: http://forums.iis.net/t/1177964.aspx und http://learn.iis.net/page.aspx/244/how-to-take-advantage-of- the-iis-integrierte-Pipeline /

Das ist ein alter Thread, aber ich bin darauf gestoßen und habe das gleiche Problem wie Egil bekommen. Hier ist die Version von Joels Korrektur, die Rollen enthält:

           

Ich wollte wissen, warum es erforderlich ist, Module (mit Standardoptionen), die standardmäßig für die integrierte Pipeline hinzugefügt werden, erneut hinzuzufügen, also habe ich ein wenig tiefer geforscht.

Sie müssen die Module entfernen und erneut hinzufügen, da die Module standardmäßig nicht mit den Standardoptionen hinzugefügt werden. Sie haben eine Vorbedingung, die aus Gründen der Abwärtskompatibilität hinzugefügt wurde, sodass sie nur für Inhalt ausgeführt wird, der von einem registrierten ASP.NET-Handler ausgeführt wird (z. B. ASPX-Seiten).

Der Standardwert sieht folgendermaßen aus:

  

Indem Sie die Module entfernen und ohne Vorbedingung neu hinzufügen, werden diese einzelnen Module für jede Anfrage (einschließlich Ihres statischen Inhalts) ausgeführt. Es ist runAllManagedModulesForAllRequests als das Aktivieren von runAllManagedModulesForAllRequests .

Sie können in einigen Artikeln darüber lesen, wann die Integrierte Pipeline mit IIS 7 eingeführt wurde:

  • ASP.NET-Integration mit IIS 7
  • Wie Sie die integrierte IIS 7.0-Pipeline nutzen können

Beachten Sie, dass ein Tipperrors oder der FormsAuthenticationModule im zweiten Artikel (und @ Johns Antwort) FormsAuthenticationModule von FormsAuthenticationModule in FormsAuthentication geändert wurde.

Die Menge der Arbeitsmodule in IIS 7.5 bis 8.5 sieht für mich so aus:

              

Nachtrag:

Wie @eych bemerkt, blockiert dies auch den Zugriff auf den Ordner ~/Content (oder wo immer Sie Ihr CSS haben) und ~/Scripts und so weiter.

Wenn Sie Ausnahmen zulassen wollen – dh bestimmten Benutzern erlauben, auf bestimmte Dateien / Ordner zuzugreifen – können Sie das mit dem location Element tun. Fügen Sie web.config Folgendes web.config :

         

Update: Eine bessere Lösung besteht darin, den Zugriff standardmäßig zu lassen – was den Zugriff auf Ihr CSS / JavaScript / etc. ermöglicht – und die “Sperre” (nur) auf den Ordner anzuwenden, in dem der statische Inhalt gespeichert ist:

        

Vorbehalt: In unserem Fall (eine MVC-Site) mussten wir alle Controller-Aktionen (außer Login) mit [AuthorizeAttribute] dekorieren. Das ist eh eine gute Idee, war aber vorher nicht nötig (da zuvor jede nicht autorisierte Anfrage auf die Login-Seite umgeleitet wurde).

Wenn der Anwendungspool im klassischen Modus ausgeführt wird, können Sie Folgendes tun. Sie müssen diese Schritte für jede Dateierweiterung wiederholen, die Sie behandeln möchten, aber ich verwende .html hier.

Fügen Sie zunächst der Web.config einen Seitenerstellungs-Provider hinzu:

 < ?xml version="1.0" encoding="UTF-8"?>          

Fügen Sie dann eine Seitenhandler-Factory hinzu:

 < ?xml version="1.0" encoding="UTF-8"?>        

Fügen Sie dann einen Seitenhandler hinzu:

 < ?xml version="1.0" encoding="UTF-8"?>         

Das hat für mich funktioniert. (Kredit: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages .)