Grundlegende Unterschiede zwischen IIS und dem ASP.NET Development Server (VB)

von Scott Mitchell

PDF herunterladen

Wenn Sie eine ASP.NET Anwendung lokal testen, können Sie wahrscheinlich den ASP.NET Development Web Server verwenden. Die Produktionswebsite wird jedoch höchstwahrscheinlich von IIS betrieben. Es gibt einige Unterschiede zwischen der Behandlung von Anforderungen auf diesen Webservern, und diese Unterschiede können wichtige Konsequenzen haben. In diesem Lernprogramm werden einige der deutschen Unterschiede untersucht.

Einführung

Wenn ein Benutzer eine ASP.NET Anwendung besucht, sendet sein Browser eine Anfrage an die Website. Diese Anforderung wird von der Webserversoftware abgerufen, die mit der ASP.NET Laufzeit koordiniert wird, um den Inhalt für die angeforderte Ressource zu generieren und zurückzugeben. DieI nternet I nformation S Ervices (IIS) sind eine Reihe von Diensten, die allgemeine internetbasierte Funktionen für Windows-Server bereitstellen. IIS ist der am häufigsten verwendete Webserver für ASP.NET Anwendungen in Produktionsumgebungen; Es ist höchstwahrscheinlich die Webserversoftware, die von Ihrem Webhostanbieter verwendet wird, um Ihre ASP.NET-Anwendung zu bedienen. IIS kann auch als Webserversoftware in der Entwicklungsumgebung verwendet werden, obwohl dies erfordert, IIS zu installieren und ordnungsgemäß zu konfigurieren.

Der ASP.NET Development Server ist eine alternative Option für einen Webserver in der Entwicklungsumgebung; er wird mit Visual Studio ausgeliefert und darin integriert. Sofern die Webanwendung nicht für die Verwendung von IIS konfiguriert wurde, wird der ASP.NET Development Server automatisch gestartet und beim ersten Besuch einer Webseite in Visual Studio als Webserver verwendet. Die demo-Webanwendungen, die wir im Lernprogramm "Bestimmen, welche Dateien bereitgestellt werden müssen " erstellt haben, waren dateisystembasierte Webanwendungen, die nicht für die Verwendung von IIS konfiguriert wurden. Daher wird beim Besuch einer dieser Websites in Visual Studio der ASP.NET Development Server verwendet.

In einer perfekten Welt wären die Entwicklungs- und Produktionsumgebungen identisch. Wie im vorherigen Lernprogramm erläutert, ist es jedoch nicht ungewöhnlich, dass die Umgebungen unterschiedliche Konfigurationseinstellungen aufweisen. Die Verwendung verschiedener Webserversoftware in den Umgebungen fügt eine weitere Variable hinzu, die bei der Bereitstellung einer Anwendung berücksichtigt werden muss. In diesem Lernprogramm werden die wichtigsten Unterschiede zwischen IIS und dem ASP.NET Development Server behandelt. Aufgrund dieser Unterschiede gibt es Szenarien, in denen Code, der einwandfrei in der Entwicklungsumgebung ausgeführt wird, eine Ausnahme auslöst oder sich bei der Ausführung in der Produktion anders verhält.

Unterschiede im Sicherheitskontext

Wenn die Webserversoftware eine eingehende Anforderung verarbeitet, ordnet sie diese Anforderung einem bestimmten Sicherheitskontext zu. Diese Sicherheitskontextinformationen werden vom Betriebssystem verwendet, um zu bestimmen, welche Aktionen von der Anforderung zulässig sind. Eine ASP.NET-Seite kann z. B. Code enthalten, der eine Nachricht in einer Datei auf der Festplatte protokolliert. Damit diese ASP.NET Seite ohne Fehler ausgeführt werden kann, muss der Sicherheitskontext über die entsprechenden Berechtigungen auf Dateisystemebene verfügen, nämlich Berechtigungen für diese Datei schreiben.

Der ASP.NET Development Server ordnet eingehende Anforderungen dem Sicherheitskontext des aktuell angemeldeten Benutzers zu. Wenn Sie als Administrator bei Ihrem Desktop angemeldet sind, haben die ASP.NET Seiten, die vom ASP.NET Development Server bereitgestellt werden, dieselben Zugriffsrechte wie ein Administrator. Von IIS verarbeitete ASP.NET-Anforderungen sind jedoch einem bestimmten Maschinenkonto zugeordnet. Standardmäßig wird das Netzwerkdienstcomputerkonto von IIS-Versionen 6 und 7 verwendet, obwohl Ihr Webhostanbieter möglicherweise ein eindeutiges Konto für jeden Kunden konfiguriert hat. Darüber hinaus hat Ihr Webhostanbieter wahrscheinlich eingeschränkte Berechtigungen für dieses Computerkonto erteilt. Das Nettoergebnis ist, dass Sie möglicherweise Webseiten haben, die ohne Fehler in der Entwicklungsumgebung ausgeführt werden, aber autorisierungsbezogene Ausnahmen generieren, wenn sie in der Produktionsumgebung gehostet werden.

Um diesen Fehlertyp in Aktion zu zeigen, habe ich eine Seite auf der Website "Buchrezensionen" erstellt, die eine Datei auf dem Datenträger erstellt, die das neueste Datum und die Uhrzeit speichert, zu der jemand die Rezension zu Bringen Sie sich ASP.NET 3.5 in 24 Stunden bei angesehen hat. Öffnen Sie die ~/Tech/TYASP35.aspx-Seite und fügen Sie dem Ereignishandler den folgenden Page_Load-Code hinzu.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As  System.EventArgs) Handles Me.Load

    Dim filePath As  String = Server.MapPath("~/LastTYASP35Access.txt")

    Dim contents As  String = String.Format("Last accessed on {0} by {1}", _

                                 DateTime.Now.ToString(), Request.UserHostAddress)

     System.IO.File.WriteAllText(filePath, contents)

End Sub

Besuchen Sie als nächstes die Buchbesprechungsseite von Teach Yourself ASP.NET 3.5 in 24 Hours in der Entwicklungsumgebung mit dem ASP.NET Development Server. Angenommen, Sie sind mit einem Konto angemeldet, das über ausreichende Berechtigungen zum Erstellen und Ändern einer Textdatei im Stammverzeichnis der Webanwendung verfügt, wird die Buchüberprüfung wie zuvor angezeigt, aber jedes Mal, wenn die Seite besucht wird, das Datum und die Uhrzeit und die IP-Adresse des Benutzers in der LastTYASP35Access.txt Datei gespeichert. Verweisen Sie Ihren Browser auf diese Datei; Es sollte eine Meldung wie in Abbildung 1 angezeigt werden.

Abbildung 1: Die Textdatei enthält das letzte Datum und die Uhrzeit, zu der die Buchüberprüfung besucht wurde(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Stellen Sie die Webanwendung in die Produktionsumgebung bereit und besuchen Sie dann die gehostete Teach Yourself ASP.NET 3.5 in 24 Stunden Buchrezensionsseite. An diesem Punkt sollten Sie entweder die Buchrezensionsseite wie gewohnt sehen oder die in Abbildung 2 dargestellte Fehlermeldung. Einige Webhostanbieter gewähren Schreibberechtigungen für das anonyme ASP.NET Computerkonto, in diesem Fall funktioniert die Seite ohne Fehler. Wenn Ihr Webhostanbieter jedoch den Schreibzugriff für das anonyme Konto verbietet, wird eine UnauthorizedAccessException Ausnahme ausgelöst, wenn die TYASP35.aspx Seite versucht, das aktuelle Datum und die aktuelle Uhrzeit in die LastTYASP35Access.txt Datei zu schreiben.

Abbildung 2: Das von IIS verwendete Standardcomputerkonto verfügt nicht über Die Berechtigung zum Schreiben in das Dateisystem (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Die gute Nachricht ist, dass die meisten Webhostanbieter über eine Art von Berechtigungstool verfügen, mit dem Sie Dateisystemberechtigungen in Ihrer Website angeben können. Gewähren Sie dem anonymen ASP.NET-Konto Schreibzugriff auf das Stammverzeichnis, und überprüfen Sie dann die Buchrezensionsseite. (Wenden Sie sich bei Bedarf an Ihren Webhostanbieter, um Hilfe zum Erteilen von Schreibberechtigungen für das Standardkonto ASP.NET zu erhalten.) Diesmal sollte die Seite ohne Fehler geladen werden, und die LastTYASP35Access.txt Datei sollte erfolgreich erstellt werden.

Da der ASP.NET Development Server unter einem anderen Sicherheitskontext als IIS ausgeführt wird, ist es möglich, dass Ihre ASP.NET-Seiten, die aus dem Dateisystem lesen oder in das Dateisystem schreiben, aus dem Windows-Ereignisprotokoll lesen oder in dieses schreiben oder aus der Windows-Registrierung lesen oder in diese schreiben, bei der Entwicklung wie erwartet funktionieren, jedoch zu Ausnahmen in der Produktion führen. Wenn Sie eine Webanwendung erstellen, die in einer freigegebenen Webhostingumgebung bereitgestellt wird, lesen oder schreiben Sie nicht in das Ereignisprotokoll oder die Windows-Registrierung. Notieren Sie sich auch alle ASP.NET Seiten, die aus dem Dateisystem lesen oder in das Dateisystem schreiben, da Sie möglicherweise Lese- und Schreibberechtigungen für die entsprechenden Ordner in der Produktionsumgebung erteilen müssen.

Unterschiede bei der Bereitstellung statischer Inhalte

Ein weiterer Hauptunterschied zwischen IIS und dem ASP.NET Development Server ist die Behandlung von Anforderungen für statische Inhalte. Jede Anforderung, die in den ASP.NET Development Server eingeht, ob für eine ASP.NET Seite, ein Bild oder eine JavaScript-Datei, wird von der ASP.NET Laufzeit verarbeitet. Standardmäßig ruft IIS die ASP.NET Laufzeit nur auf, wenn eine Anforderung für eine ASP.NET Ressource eingeht, z. B. eine ASP.NET Webseite, einen Webdienst usw. Anforderungen für statische Inhalte – Bilder, CSS-Dateien, JavaScript-Dateien, PDF-Dateien, ZIP-Dateien und ähnliches – werden von IIS ohne Beteiligung der ASP.NET Laufzeit abgerufen. (Es ist möglich, IIS anzuweisen, mit der ASP.NET Laufzeit zu arbeiten, wenn statische Inhalte bereitgestellt werden. Weitere Informationen finden Sie im Abschnitt "Ausführen Forms-Based Authentifizierung und URL-Authentifizierung für statische Dateien mit IIS 7".)

Die ASP.NET Laufzeit führt eine Reihe von Schritten aus, um die angeforderten Inhalte zu generieren, einschließlich Authentifizierung (Identifizieren des Anforderers) und Autorisierung (bestimmen, ob der Antragsteller über die Berechtigung zum Anzeigen des angeforderten Inhalts verfügt). Eine beliebte Form der Authentifizierung ist die formularbasierte Authentifizierung, bei der ein Benutzer durch Eingabe seiner Anmeldeinformationen – in der Regel einen Benutzernamen und ein Kennwort – in Textfelder auf einer Webseite identifiziert wird. Bei der Überprüfung ihrer Anmeldeinformationen speichert die Website ein Authentifizierungsticket-Cookie im Browser des Benutzers, das mit jeder nachfolgenden Anforderung an die Website gesendet wird und was zur Authentifizierung des Benutzers verwendet wird. Darüber hinaus ist es möglich, URL-Autorisierungsregeln anzugeben, die festlegen, welche Benutzer auf einen bestimmten Ordner zugreifen können oder nicht zugreifen können. Viele ASP.NET Websites verwenden formularbasierte Authentifizierung und URL-Autorisierung, um Benutzerkonten zu unterstützen und Teile der Website zu definieren, die nur für authentifizierte Benutzer oder Benutzer zugänglich sind, die zu einer bestimmten Rolle gehören.

Erwägen Sie eine Website, die Benutzerkonten mit formularbasierter Autorisierung unterstützt und über einen Ordner verfügt, der mithilfe der URL-Autorisierung so konfiguriert ist, dass nur authentifizierte Benutzer zugelassen werden. Stellen Sie sich vor, dass dieser Ordner ASP.NET Seiten und PDF-Dateien enthält und dass nur authentifizierte Benutzer diese PDF-Dateien anzeigen können.

Was geschieht, wenn ein Besucher versucht, eine dieser PDF-Dateien anzuzeigen, indem er die URL direkt in die Adressleiste seines Browsers eingibt? Um herauszufinden, erstellen wir einen neuen Ordner auf der Website "Buchüberprüfungen", fügen einige PDF-Dateien hinzu und konfigurieren die Website so, dass die URL-Autorisierung verwendet wird, um zu verhindern, dass anonyme Benutzer diesen Ordner besuchen. Wenn Sie die Demoanwendung herunterladen, sehen Sie, dass ich einen Ordner mit dem Namen PrivateDocs erstellt und eine PDF aus meinen Website Security Tutorials (wie passend!) hinzugefügt habe. Der PrivateDocs Ordner enthält auch eine Web.config Datei, die die URL-Autorisierungsregeln angibt, um anonyme Benutzer zu verweigern:

<?xml version="1.0"?>

<configuration>

    <system.web>

         <authorization>

            <deny  users="?" />

         </authorization>

     </system.web>

</configuration>

Schließlich habe ich die Webanwendung so konfiguriert, dass die formularbasierte Authentifizierung verwendet wird, indem die Web.config Datei im Stammverzeichnis aktualisiert und ersetzt wird:

<authentication mode="Windows" />

Mit:

<authentication mode="Forms" />

Besuchen Sie mit dem ASP.NET Development Server die Website, und geben Sie die direkte URL zu einer der PDF-Dateien in der Adressleiste Ihres Browsers ein. Wenn Sie die website heruntergeladen haben, die diesem Lernprogramm zugeordnet ist, sollte die URL ungefähr wie folgt aussehen: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf

Wenn Sie diese URL in die Adressleiste eingeben, sendet der Browser eine Anforderung an den ASP.NET Development Server für die Datei. Der ASP.NET Development Server übergibt die Anforderung an die ASP.NET Laufzeit für die Verarbeitung. Da wir noch nicht angemeldet sind und weil der Web.configPrivateDocs Ordner so konfiguriert ist, dass anonymer Zugriff verweigert wird, leitet die ASP.NET Laufzeit uns automatisch an die Anmeldeseite Login.aspx weiter (siehe Abbildung 3). Beim Umleiten des Benutzers zur Anmeldeseite enthält ASP.NET einen ReturnUrl Abfragezeichenfolgenparameter, der angibt, welche Seite der Benutzer anzeigen wollte. Nach erfolgreichem Einloggen kann der Benutzer zu dieser Seite zurückgeleitet werden.

Abbildung 3: Nicht autorisierte Benutzer werden automatisch zur Anmeldeseite umgeleitet (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Sehen wir uns nun an, wie sich dies bei der Produktion verhält. Stellen Sie Ihre Anwendung bereit, und geben Sie die direkte URL zu einer der PDF-Dateien im PrivateDocs-Ordner in der Produktion ein. Dadurch wird Ihr Browser aufgefordert, eine IIS-Anforderung für die Datei zu senden. Da eine statische Datei angefordert wird, ruft IIS die Datei ab und gibt sie zurück, ohne die ASP.NET Laufzeit aufzufordern. Daher wurde keine URL-Autorisierungsprüfung durchgeführt; Der Inhalt der angeblich privaten PDF ist für jeden zugänglich, der die direkte URL zu der Datei kennt.

Abbildung 4: Anonyme Benutzer können die privaten PDF-Dateien herunterladen, indem Sie die direkte URL in die Datei eingeben (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Das Ausführen der formsbasierten Authentifizierung und der URL-Authentifizierung von statischen Dateien mit IIS 7

Es gibt eine Reihe von Techniken, mit denen Sie statische Inhalte vor nicht autorisierten Benutzern schützen können. IIS 7 hat die integrierte Pipeline eingeführt, die den IIS-Workflow mit dem Workflow der ASP.NET-Laufzeit kombiniert. Kurz gesagt, Sie können IIS anweisen, die Authentifizierungs- und Autorisierungsmodule der ASP.NET Laufzeit alle eingehenden Anforderungen (einschließlich statischer Inhalte wie PDF-Dateien) aufzurufen. Wenden Sie sich an Ihren Webhostanbieter, um zu erfahren, wie Sie Ihre Website für die Verwendung der integrierten Pipeline konfigurieren.

Nachdem IIS für die Verwendung der integrierten Pipeline konfiguriert wurde, fügen Sie der Datei im Stammverzeichnis das folgende Markup hinzu Web.config :

<system.webServer>

      <modules>

          <add  name="FormsAuthenticationModule"  type="System.Web.Security.FormsAuthenticationModule" />

          <remove  name="UrlAuthorization" />

          <add  name="UrlAuthorization"  type="System.Web.Security.UrlAuthorizationModule" />

          <remove  name="DefaultAuthentication" />

          <add  name="DefaultAuthentication"  type="System.Web.Security.DefaultAuthenticationModule" />

      </modules>

</system.webServer>

Dieses Markup weist IIS 7 an, die auf ASP.NET basierenden Authentifizierungs- und Autorisierungsmodule zu verwenden. Stellen Sie Ihre Anwendung erneut bereit, und besuchen Sie dann die PDF-Datei erneut. Dieses Mal, wenn IIS die Anforderung verarbeitet, erhält die ASP.NET Authentifizierungs- und Autorisierungslogik der Laufzeit die Möglichkeit, die Anforderung zu prüfen. Da nur authentifizierte Benutzer berechtigt sind, den Inhalt im PrivateDocs Ordner anzuzeigen, wird der anonyme Besucher automatisch auf die Anmeldeseite umgeleitet (siehe Abbildung 3).

Zusammenfassung

Webanwendungen in einer Produktionsumgebung werden mithilfe der IIS-Webserversoftware von Microsoft gehostet. In der Entwicklungsumgebung kann die Anwendung jedoch mit IIS oder dem ASP.NET Development Server gehostet werden. Im Idealfall sollte die gleiche Webserversoftware in beiden Umgebungen verwendet werden, da die Verwendung unterschiedlicher Software eine weitere Variable in der Mischung hinzufügt. Die benutzerfreundlichkeit des ASP.NET Development Server macht es jedoch in der Entwicklungsumgebung zu einer attraktiven Wahl. Die gute Nachricht ist, dass es nur ein paar grundlegende Unterschiede zwischen IIS und dem ASP.NET Development Server gibt, und wenn Sie sich dieser Unterschiede bewusst sind, können Sie Schritte unternehmen, um sicherzustellen, dass die Anwendung unabhängig von der Umgebung auf die gleiche Weise funktioniert und funktioniert.

Glückliche Programmierung!

Weiterführende Lektüre

Weitere Informationen zu den in diesem Lernprogramm erläuterten Themen finden Sie in den folgenden Ressourcen:

• ASP.NET Integration in IIS 7.0
• Verwendung der ASP.NET-Forenauthentifizierung mit allen Inhaltstypen in IIS 7 (Video)
• Webserver in Visual Web Developer