Wichtige Unterschiede zwischen den IIS und ASP.NET Development Server (VB)
von Scott Mitchell
Wenn Sie eine ASP.NET Anwendung lokal testen, ist es wahrscheinlich, dass Sie den ASP.NET Development Web Server verwenden. Die Produktionswebsite ist jedoch höchstwahrscheinlich mit IIS versorgt. Es gibt einige Unterschiede zwischen der Verarbeitung von Anforderungen durch diese Webserver, und diese Unterschiede können wichtige Konsequenzen haben. In diesem Tutorial werden einige der eher deutschen Unterschiede 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 aufgenommen, die sich 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. Dies 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, dass IIS installiert und ordnungsgemäß konfiguriert wird.
Der ASP.NET Development Server ist eine alternative Webserveroption für die Entwicklungsumgebung. es ist 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 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 Tutorial erläutert, ist es jedoch nicht ungewöhnlich, dass die Umgebungen unterschiedliche Konfigurationseinstellungen aufweisen. Durch die Verwendung verschiedener Webserversoftware in den Umgebungen wird eine weitere Variable hinzugefügt, die beim Bereitstellen 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 fehlerfrei 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, 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. Beispielsweise kann eine ASP.NET Seite Code enthalten, der eine Nachricht in einer Datei auf dem Datenträger 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 über Schreibberechtigungen für diese Datei.
Der ASP.NET Development Server ordnet eingehende Anforderungen dem Sicherheitskontext des aktuell angemeldeten Benutzers zu. Wenn Sie auf Ihrem Desktop als Administrator 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 Webseiten möglicherweise ohne Fehler in der Entwicklungsumgebung 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, auf der eine Datei auf dem Datenträger erstellt wird, die das letzte Datum und die Uhrzeit speichert, zu der jemand die Überprüfung von Teach Yourself ASP.NET 3.5 in 24 Stunden angezeigt hat. Öffnen Sie dazu die ~/Tech/TYASP35.aspx Seite, und fügen Sie dem Ereignishandler den Page_Load folgenden 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
Hinweis
Die File.WriteAllText -Methode erstellt eine neue Datei, wenn sie nicht vorhanden ist, und schreibt dann den angegebenen Inhalt in die Datei. 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 " in der Entwicklungsumgebung mit dem ASP.NET Development Server. Unter der Annahme, dass Sie bei Ihrem Computer mit einem Konto angemeldet sind, 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. Verweisen Sie Ihren Browser auf diese Datei; Es sollte eine Meldung ähnlich der in Abbildung 1 dargestellten angezeigt werden.
Abbildung 1: Die Textdatei enthält das Datum und die Uhrzeit des letzten Besuchs der Buchprü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 der 24-Stunden-Buchüberprüfungsseite . An diesem Punkt sollte entweder die Buchüberprüfungsseite normal oder die in Abbildung 2 dargestellte Fehlermeldung 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 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 hat keine Berechtigungen 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 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 die Seite "Buchüberprüfung". (Wenden Sie sich bei Bedarf an Ihren Webhostanbieter, um Unterstützung beim Erteilen von Schreibberechtigungen für das Standardkonto ASP.NET zu erhalten.) Dieses Mal 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 das Dateisystem lesen oder in das Dateisystem schreiben, aus dem Windows-Ereignisprotokoll lesen oder in das Windows-Ereignisprotokoll schreiben oder in die Windows-Registrierung lesen oder in die Windows-Registrierung schreiben, bei der Entwicklung wie erwartet funktionieren, aber Ausnahmen in der Produktion generieren. Wenn Sie eine Webanwendung erstellen, die in einer freigegebenen Webhostingumgebung bereitgestellt wird, sollten Sie weder das Ereignisprotokoll noch die Windows-Registrierung lesen oder schreiben. Beachten Sie 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 Verarbeitung von Anforderungen für statische Inhalte. Jede Anforderung, die in 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. für 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, bei der Bereitstellung statischer Inhalte mit der ASP.NET Runtime zu arbeiten. Weitere Informationen finden Sie im Abschnitt "Ausführen von Forms-Based Authentifizierung und URL-Authentifizierung für statische Dateien mit IIS 7" in diesem Tutorial.)
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 (bestimmen, 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 identifiziert wird, indem er seine Anmeldeinformationen - in der Regel einen Benutzernamen und ein Kennwort - in Textfelder auf einer Webseite eingibt. Nach der Validierung 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 Untersuchung von ASP. Die formularbasierte Authentifizierung von NET, die URL-Autorisierung und andere Benutzerkontobezogene Features finden Sie in den Tutorials zur Websitesicherheit.
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, 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 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 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-Sicherheitstutorials 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"?>
<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 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 in etwa 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 zur Verarbeitung an die ASP.NET Runtime. Da wir noch nicht angemeldet sind und der Web.config im PrivateDocs Ordner so konfiguriert ist, dass anonymer Zugriff verweigert wird, leitet uns die ASP.NET Runtime automatisch zur Anmeldeseite Login.aspx um (siehe Abbildung 3). Wenn der Benutzer zur Anmeldeseite umgeleitet wird, enthält ASP.NET einen ReturnUrl Querystring-Parameter, der die Seite angibt, die der Benutzer anzuzeigen versucht hat. 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 aufzufordern. Daher wurde keine URL-Autorisierungsprüfung durchgeführt. der Inhalt der angeblich privaten PDF-Datei 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 für die Datei eingeben (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)
Ausführen Forms-Based Authentifizierung und URL-Authentifizierung für statische 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 führte die integrierte Pipeline ein, die den IIS-Workflow mit dem Workflow der ASP.NET Runtime zusammenführt. Kurz gesagt, Sie können 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 dann erneut die PDF-Datei. Wenn IIS die Anforderung dieses Mal verarbeitet, gibt es der ASP.NET Authentifizierungs- und Autorisierungslogik der 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 umgeleitet (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 verhindert (z App_Data. B. ), und dann eine Seite zum Bereitstellen dieser Dokumente zu erstellen. Diese Seite kann als aufgerufen GetPDF.aspxwerden, und der Name der PDF-Datei 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, verwendet die Response.WriteFile(filePath) -Methode, um den Inhalt der angeforderten PDF-Datei zurück an den anfordernden Client zu senden. Diese Technik würde auch für IIS 7 funktionieren, wenn Sie die integrierte Pipeline nicht aktivieren möchten.
Zusammenfassung
Webanwendungen in einer Produktionsumgebung werden mit 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 verschiedener 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 wenige 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 genauso funktioniert und funktioniert.
Viel Spaß beim Programmieren!
Weitere Informationen
Weitere Informationen zu den in diesem Tutorial behandelten Themen finden Sie in den folgenden Ressourcen:
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für