Wichtige Unterschiede zwischen den IIS und dem ASP.NET Development Server (C#)
von Scott Mitchell
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 unterstützt. Es gibt einige Unterschiede zwischen der Verarbeitung von Anforderungen durch diese Webserver, und diese Unterschiede können wichtige Folgen haben. In diesem Tutorial werden einige der größeren Deutschunterschiede untersucht.
Einführung
Wenn ein Benutzer eine ASP.NET Anwendung besucht, sendet sein Browser eine Anforderung an die Website. Diese Anforderung wird von der Webserversoftware abgerufen, die mit der ASP.NET Runtime koordiniert, 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 handelt sich höchstwahrscheinlich um 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 die Installation von IIS und die ordnungsgemäße Konfiguration erfordert.
Der ASP.NET Development Server ist eine alternative Webserveroption für die Entwicklungsumgebung. es wird im Lieferumfang enthalten und ist in Visual Studio 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 Tutorial Zur Bestimmung, 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 wir im vorherigen Tutorial erläutert haben, ist es jedoch nicht ungewöhnlich, dass die Umgebungen unterschiedliche Konfigurationseinstellungen aufweisen. Die Verwendung unterschiedlicher Webserversoftware in den Umgebungen fügt eine weitere Variable hinzu, die bei der Bereitstellung einer Anwendung berücksichtigt werden muss. In diesem Tutorial 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 anders verhält, wenn er in der Produktion ausgeführt wird.
Unterschiede im Sicherheitskontext
Wenn die Webserversoftware eine eingehende Anforderung verarbeitet, verknüpft sie diese Anforderung mit einem bestimmten Sicherheitskontext. Diese Sicherheitskontextinformationen werden vom Betriebssystem verwendet, um zu bestimmen, welche Aktionen von der Anforderung zulässig sind. Beispielsweise kann eine ASP.NET Seite Code enthalten, der eine Nachricht in einer Datei auf dem Datenträger protokolliert. Damit diese ASP.NET Seite fehlerfrei ausgeführt werden kann, muss der Sicherheitskontext über die entsprechenden Berechtigungen auf Dateisystemebene verfügen, d. h. Schreibberechtigungen für diese Datei.
Der ASP.NET Development Server ordnet eingehende Anforderungen dem Sicherheitskontext des aktuell angemeldeten Benutzers zu. Wenn Sie als Administrator bei Ihrem Desktop angemeldet sind, verfügen die ASP.NET Seiten, die vom ASP.NET Development Server bereitgestellt werden, über dieselben Zugriffsrechte wie ein Administrator. ASP.NET Anforderungen, die von IIS verarbeitet werden, sind jedoch einem bestimmten Computerkonto zugeordnet. Standardmäßig wird das Computerkonto des Netzwerkdiensts von den 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 in der Entwicklungsumgebung fehlerfrei ausgeführt werden, aber autorisierungsbezogene Ausnahmen generieren, wenn sie in der Produktionsumgebung gehostet werden.
Um diese Art von Fehler in Aktion anzuzeigen, habe ich eine Seite auf der Website "Buchbewertungen" erstellt, die eine Datei auf dem Datenträger erstellt, die das letzte Datum und die Uhrzeit speichert, zu der jemand die Überprüfung "Teach Yourself ASP.NET 3.5 in 24 Stunden " angezeigt hat. Öffnen Sie die ~/Tech/TYASP35.aspx Seite, und fügen Sie dem Ereignishandler den folgenden Code Page_Load hinzu:
protected void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);
System.IO.File.WriteAllText(filePath, contents);
}
Hinweis
Die File.WriteAllText -Methode erstellt eine neue Datei, falls sie nicht vorhanden ist, und schreibt dann den angegebenen Inhalt in sie. Wenn die Datei bereits vorhanden ist, wird der vorhandene Inhalt überschrieben.
Besuchen Sie als Nächstes die Seite Teach Yourself ASP.NET 3.5 in 24 Stunden buch review in der Entwicklungsumgebung mithilfe des ASP.NET Development Server. Angenommen, Sie sind bei Ihrem Computer 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, werden Datum und Uhrzeit sowie die IP-Adresse des Benutzers in der LastTYASP35Access.txt Datei gespeichert. Zeigen Sie Ihren Browser auf diese Datei. Es sollte eine Meldung ähnlich der in Abbildung 1 gezeigten angezeigt werden.
Abbildung 1: Die Textdatei enthält das letzte Datum und die Uhrzeit des Besuchs der Buchüberprüfung (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
Stellen Sie die Webanwendung in der Produktion bereit, und besuchen Sie dann die gehostete Seite Teach Yourself ASP.NET 3.5 in 24 Stunden Buchbewertung. An diesem Punkt sollte entweder die Buchüberprüfungsseite normal oder die Fehlermeldung in Abbildung 2 angezeigt werden. Einige Webhostanbieter erteilen 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 untersagt, 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 Berechtigungen zum Schreiben in das Dateisystem (klicken, um das bild in voller Größe anzuzeigen)
Die gute Nachricht ist, dass die meisten Webhostanbieter über ein Berechtigungstool verfügen, mit dem Sie Dateisystemberechtigungen auf Ihrer Website angeben können. Gewähren Sie dem anonymen ASP.NET Konto Schreibzugriff auf das Stammverzeichnis, und besuchen Sie dann erneut die Seite "Buchbesichtigung". (Wenden Sie sich bei Bedarf an Ihren Webhostanbieter, um Hilfe beim 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 arbeitet, ist es möglich, dass Ihre ASP.NET Seiten, die das Dateisystem lesen oder in das Dateisystem schreiben, aus dem Windows-Ereignisprotokoll lesen oder in das Windows-Ereignisprotokoll schreiben oder lesen oder in die Windows-Registrierung schreiben, bei der Entwicklung wie erwartet funktionieren, bei der Produktion jedoch Ausnahmen generieren. 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 außerdem 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 wichtiger Unterschied zwischen IIS und dem ASP.NET Development Server ist die Verarbeitung von Anforderungen für statische Inhalte. Jede Anforderung, die an den ASP.NET Development Server eingeht, unabhängig davon, ob es sich um eine ASP.NET Seite, ein Image oder eine JavaScript-Datei handelt, wird von der ASP.NET Runtime verarbeitet. Standardmäßig ruft IIS die ASP.NET Runtime 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 usw. – werden von IIS ohne Beteiligung der ASP.NET Runtime abgerufen. (Es ist möglich, IIS anzuweisen, mit der ASP.NET Runtime 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 Runtime führt eine Reihe von Schritten aus, um den angeforderten Inhalt zu generieren, einschließlich Authentifizierung (Identifizierung des Anforderers) und Autorisierung (ermitteln, ob der Anforderer ü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 ein Benutzername und ein Kennwort - in Textfelder auf einer Webseite identifiziert wird. Nach der Überprüfung der Anmeldeinformationen speichert die Website ein Authentifizierungsticket-Cookie im Browser des Benutzers, das mit jeder nachfolgenden Anforderung an die Website gesendet wird und 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. Viele ASP.NET Websites verwenden formularbasierte Authentifizierung und URL-Autorisierung, um Benutzerkonten zu unterstützen und Teile der Website zu definieren, auf die nur authentifizierte Benutzer oder Benutzer zugreifen können, die einer bestimmten Rolle angehören.
Hinweis
Für eine gründliche Prüfung von ASP. Die formularbasierte Authentifizierung, URL-Autorisierung und andere Features, die sich auf das Benutzerkonto beziehen, sollten Sie sich unbedingt meine Tutorials zur Websitesicherheit ansehen.
Stellen Sie sich eine Website vor, 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, dieser Ordner enthält ASP.NET Seiten und PDF-Dateien und die Absicht besteht darin, 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 dies herauszufinden, erstellen wir einen neuen Ordner auf der Website Buchbewertungen, fügen einige PDF-Dateien hinzu und konfigurieren die Website so, dass die URL-Autorisierung verwendet wird, um anonymen Benutzern den Besuch dieses Ordners zu verbieten. Wenn Sie die Demoanwendung herunterladen, sehen Sie, dass ich einen Ordner mit dem Namen PrivateDocs erstellt und eine PDF aus meinen Website Security Tutorials hinzugefügt habe (wie passend!). Der PrivateDocs Ordner enthält auch eine Web.config Datei, die die URL-Autorisierungsregeln angibt, um anonyme Benutzer zu verweigern:
<?xml version="1.0"?>
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Schließlich habe ich die Webanwendung für die Verwendung der formularbasierten Authentifizierung konfiguriert, indem ich die Web.config Datei im Stammverzeichnis aktualisiert habe und folgendes ersetzte:
<authentication mode="Windows" />
durch:
<authentication mode="Forms" />
Besuchen Sie mithilfe des 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 Tutorial 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 Runtime für die Verarbeitung. Da wir uns noch nicht angemeldet haben und der Web.config im PrivateDocs Ordner so konfiguriert ist, dass der anonyme Zugriff verweigert wird, leitet uns die ASP.NET Runtime automatisch zur Anmeldeseite Login.aspx weiter (siehe Abbildung 3). Beim Umleiten des Benutzers zur Anmeldeseite enthält ASP.NET einen ReturnUrl Abfragezeichenfolgenparameter, der die Seite angibt, die der Benutzer anzeigen wollte. Nach erfolgreicher Anmeldung kann der Benutzer auf diese Seite zurückgesendet werden.
Abbildung 3: Nicht autorisierte Benutzer werden automatisch zur Anmeldeseite umgeleitet (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
Nun sehen wir uns an, wie sich dies in der Produktion verhält. Stellen Sie Ihre Anwendung bereit, und geben Sie die direkte URL zu einem der PDFs im Ordner in der PrivateDocs 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 Runtime aufrufen zu müssen. Infolgedessen wurde keine URL-Autorisierungsprüfung durchgeführt. der Inhalt des angeblich privaten PDF ist für jeden zugänglich, der die direkte URL zur Datei kennt.
Abbildung 4: Anonyme Benutzer können die privaten PDF-Dateien herunterladen, indem sie die direkte URL zur Datei eingeben (Klicken Sie hier, um das bild in voller Größe anzuzeigen)
Ausführen Forms-Based Authentifizierung und URL-Authentifizierung in 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 Runtime zusammenführt. Kurz gesagt können Sie IIS anweisen, die Authentifizierungs- und Autorisierungsmodule der ASP.NET Runtime für 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 Web.config folgende Markup hinzu:
<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 ASP.NET-basierten Authentifizierungs- und Autorisierungsmodule zu verwenden. Stellen Sie Ihre Anwendung erneut bereit, und besuchen Sie die PDF-Datei erneut. Wenn IIS die Anforderung dieses Mal verarbeitet, gibt es der Authentifizierungs- und Autorisierungslogik der ASP.NET Runtime die Möglichkeit, die Anforderung zu überprüfen. Da nur authentifizierte Benutzer zum Anzeigen der Inhalte im PrivateDocs Ordner autorisiert sind, wird der anonyme Besucher automatisch zur Anmeldeseite weitergeleitet (siehe Abbildung 3).
Hinweis
Wenn Ihr Webhostanbieter weiterhin IIS 6 verwendet, können Sie die integrierte Pipelinefunktion nicht verwenden. Eine Problemumgehung besteht darin, Ihre privaten Dokumente in einem Ordner zu speichern, der den HTTP-Zugriff (z. B App_Data. ) verhindert, und dann eine Seite zum Bereitstellen dieser Dokumente zu erstellen. Diese Seite kann den Namen nennen GetPDF.aspx, und der Name der PDF wird über einen Querystring-Parameter übergeben. Die GetPDF.aspx Seite überprüft zunächst, ob der Benutzer über die Berechtigung zum Anzeigen der Datei verfügt, und wenn ja, würde die Response.WriteFile(filePath) -Methode verwenden, um den Inhalt der angeforderten PDF-Datei zurück an den anfordernden Client zu senden. Dieses Verfahren funktioniert auch für IIS 7, wenn Sie die integrierte Pipeline nicht aktivieren möchten.
Zusammenfassung
Webanwendungen in einer Produktionsumgebung werden mithilfe der IIS-Webserversoftware von Microsoft gehostet. In der Entwicklungsumgebung kann die Anwendung jedoch mithilfe von IIS oder dem ASP.NET Development Server gehostet werden. Im Idealfall sollte dieselbe Webserversoftware in beiden Umgebungen verwendet werden, da die Verwendung einer anderen Software eine weitere Variable in der Mischung hinzufügt. Die Benutzerfreundlichkeit des ASP.NET Development Server macht ihn jedoch zu einer attraktiven Wahl in der Entwicklungsumgebung. Die gute Nachricht ist, dass es nur einige grundlegende Unterschiede zwischen IIS und dem ASP.NET Development Server gibt. Wenn Sie sich dieser Unterschiede bewusst sind, können Sie Maßnahmen ergreifen, um sicherzustellen, dass die Anwendung unabhängig von der Umgebung auf die gleiche Weise funktioniert und funktioniert.
Viel Spaß beim Programmieren!
Weitere Informationen
Weitere Informationen zu den in diesem Tutorial erläuterten Themen finden Sie in den folgenden Ressourcen: