Inside Microsoft.comVerwaltung und Delegierung von ASP.NET
Jeff Toews,
Die microsoft.com-Webinfrastruktur wird fast ausschließlich auf .NET Framework 2.0 ausgeführt. Eine der wichtigsten Webverwaltungsherausforderungen für das microsoft.com-Betriebsteam ist die ordnungsgemäße Konfiguration von ASP.NET, und wir haben beim Versuch, die Einstellungen zu perfektionieren, viel gelernt. Die Optimierung der
Konfigurationseinstellungen erfordert sehr gute Kenntnisse der unterschiedlichen Konfigurationsbereiche in web.config- und machine.config-Dateien sowie ein Verständnis der Auswirkung der einzelnen Einstellungen. Beispiele anzusehen, ist eine gute Möglichkeit, diese Einstellungen und deren Auswirkungen zu verstehen. In diesem Artikel werden einige Konfigurationstipps behandelt, die aus der Konfiguration der Server unter microsoft.com abgeleitet sind, sodass Sie von dieser Erfahrung profitieren können.
1. Korrektes Einstellen des Kompilierungsschalters
Beim Einsatz ASP.NET-basierter Anwendungen in einer Produktionsumgebung ist es besonders wichtig sicherzustellen, dass das Kompilierungsdebugattribut in den web.config-Dateien einer Anwendung nicht versehentlich (oder absichtlich) auf „True“ eingestellt wird, wie dies im folgenden Beispiel der Fall ist:
<compilation debug="true" />
In umfangreichen Umgebungen mit zahlreichen zu verwaltenden Webanwendungen sollte der ASP.NET-Konfigurationssteuerungsmechanismus verwendet werden, um zu blockieren, dass diese Einstellung vorgenommen werden kann. (Weitere Details hierzu folgen in Kürze.)
Außerdem ist es wichtig sicherzustellen, dass das seitenspezifische Debuggingattribut in individual .aspx nicht auf „True“ gesetzt ist, wie dies im folgenden Beispiel der Fall ist:
<%@ Page debug="true" %>
Auch hier gilt Folgendes: In umfangreichen Umgebungen mit zahlreichen Veröffentlichungen ist es oft nicht realistisch zu erwarten, dass Sie sicherstellen können, dass diese Einstellung von allen .aspx-Seiten vor deren Veröffentlichung entfernt wird. Daher benötigen Sie eine globales Methode, mit dem dies verhindert werden kann.
Das Kompilieren Ihrer Webanwendung mit dieser Einstellung führt zu höheren Debugproblemen statt höheren Verkaufszahlen. Zusätzlich wird Ihr Code hierdurch nicht optimiert, was die Leistung verlangsamt. Darüber hinaus gibt es keine Zeitüberschreitung für Ihre ASP.NET-Anfragen, da die Debugeinstellungen Zeitüberschreitungen verhindern. Das Verwenden einer Debugversion in einer Produktionsumgebung kommt einer Einladung für Hacker gleich!
Glücklicherweise verfügt Microsoft® .NET Framework 2.0 über eine neue Bereitstellungseinstellung für machine.config, über die ASP.NET angewiesen wird, Folgendes zu deaktivieren: Debugmöglichkeiten, Überwachungsausgabe und Anzeige von ASP.NET-Fehlermeldungen (sowohl auf dem lokalen Host als auch auf Remotehosts) unabhängig von den Anweisungen in der Datei web.config oder den spezifischen Seitenattributen. Das sieht folgendermaßen aus:
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
Beachten Sie, dass es sich bei den genannten beiden Vorteilen (Deaktivieren der Überwachungsausgabe und Remote-Deaktivierung detaillierter ASP.NET-Fehlermeldungen) um Sicherheitsregeln handelt, die Sie unbedingt übernehmen sollten. Wenn Sie dies nicht tun, liegen die internen Prozesse Ihrer Anwendung der ganzen Welt zur Ausnutzung offen.
Hierzu noch ein anderer wichtiger Punkt: Das Sperren des <system.web><-Kompilierungs>debugattributs in der Datei root web.config innerhalb von <location allowOverride="false"> oder das Verwenden des Attributs lockItems verhindert, dass web.config-Dateien, die in der Anwendungskonfigurationshierarchie weiter unten stehen, die Debugeinstellungen einschalten. Dadurch wird jedoch nicht verhindert, dass einzelne .aspx-Seiten den Debugmodus in deren Seitenattributen aktivieren. Der Bereitstellungsverkaufsschalter ist die einzige Möglichkeit zur vollständigen Deaktivierung von ASP.NET-Debugmöglichkeiten auf allen Ebenen.
Das Einstellen des Bereitstellungsverkaufsschalters auf „True“ ist gegebenenfalls eine bewährte Methode, der Unternehmen, die formale Produktionsserver einsetzen, unbedingt folgen sollten, um sicherzustellen, dass eine Anwendung stets mit der höchsten Leistung und ohne Sicherheitslücken betrieben wird. Wie bereits erwähnt, dieser Schalter ist ein völlig neues Merkmal von ASP.NET 2.0 und ist das direkte Ergebnis des Feedbacks an das ASP.NET-Team.
Bei intern ausgerichteten Präproduktionsumgebungen hingegen, bei denen Entwickler ihre Webanwendungen debuggen müssen, sollte die Bereitstellungsverkaufseinstellung nicht verwendet werden. Setzen Sie hierfür <compilation debug="false"> in der Präproduktionsdatei root web.config, und lassen Sie das Überschreiben dieser Einstellung durch die web.config-Dateien der einzelnen Anwendungen oder den .aspx-Seitenattributen zu.
2. Verwenden der mittleren Vertrauenswürdigkeit in ASP.NET 2.0
Wenn Sie wie bei zahlreichen Sites auf microsoft.com auch nach der Migration Ihrer Site oder Anwendungen auf ASP.NET 2.0 immer noch eine hohe Vertrauensebene verwenden, beachten Sie folgende Punkte, die zeigen, was nun mit der mittleren Vertrauenswürdigkeit möglich ist. So schränkt zum Beispiel die eingeschränkte WebPermission die Kommunikation einer Anwendung auf eine Adresse oder einen Adressbereich ein, die/den Sie im <Vertrauens>element definieren. Dadurch können Sie eine Liste von akzeptierten externen Sites und Adressbereichen steuern und verwalten, die remote aufgerufen werden können. Hierbei handelt es sich um einen hohen Sicherheitsbonus.
FileIOPermission ist auch eingeschränkt. Das bedeutet, dass der Code einer Anwendung lediglich auf Dateien in der virtuellen Verzeichnishierarchie zugreifen kann. Standardmäßig wird jeder Anwendung bei mittlerer Vertrauenswürdigkeit die Berechtigung zum Lesen, Schreiben, Anhängen und für PathDiscovery nur für die virtuelle Verzeichnishierarchie zugewiesen. Somit wird zufälligem Datei-E/A-Zugriff ein Ende bereitet, was in einer freigegebenen Webumgebung, in der zahlreiche Anwendungen gehostet werden, sehr wichtig ist.
Ein weiterer Vorteil ist, dass nicht verwaltete Codeberechtigungen entfernt werden. Dadurch können Sie die Verwendung von veralteten Komponenten verhindern, was wiederum die bisher einfachste Möglichkeit zur Deaktivierung der Verwendung des Seitenattributs Aspcompat darstellt. (Durch Einstellen von Aspcompat auf „True“ kann die Leistung von Seiten herabgesetzt werden.)
Die mittlere Vertrauenswürdigkeit unter ASP.NET 2.0 ist recht flexibel, da sie Administratoren das Erstellen benutzerspezifischer Ausnahmen für alle früheren Standardeinschränkungen ermöglicht. Diese Flexibilität war in ASP.NET 1.1 nicht gegeben. Ein weiterer Grund, warum das Ausführen der mittleren Vertrauensebene mit ASP.NET 2.0 einfacher ist als mit ASP.NET 1.1, ist der Zugriff auf die Microsoft SQL Server™-Datenbank.
Daher können Sie beim Hosten mehrerer Anwendungen auf einem Server die Codezugriffssicherheit und mittlere Vertrauenswürdigkeit für die Anwendungsisolierung verwenden. Durch Einstellen und Sperren der Vertrauensebene in der Datei root web.config (über die Tags <location allowOverride="false">) können Sie Sicherheitsrichtlinien für alle Webanwendungen auf dem Server einrichten. Durch Einstellen von allowOverride="false" (siehe Abbildung 1) können einzelne Entwickler die Einstellung zur Sicherheitsrichtlinie für die Vertrauenswürdigkeit in der Datei web.config der entsprechenden Anwendungen nicht mehr überschreiben.
Figure 1 Vertrauenseinstellungen
<configuration>
<location allowOverride="false">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</securityPolicy>
<trust level="Medium" originUrl="" />
</system.web>
</location>
</configuration>
Weitere Informationen zur Verwendung der mittleren Vertrauensebene in ASP.NET 2.0 finden Sie in folgendem Artikel: "Gewusst wie: Verwenden der mittleren Vertrauensebene in ASP.NET 2.0"
3. Einschränken des Downloads auf bestimmte Dateitypen
Es gibt Dateitypen auf Ihrem Server, die zweifelsohne nicht in die falschen Hände gelangen dürfen. ASP.NET ist standardmäßig so konfiguriert, dass Anfragen für mehrere verschiedene Dateitypen, die in ASP.NET-Anwendungen verwendet werden, abgefangen und beendet werden. Dazu gehören .config- und .cs-Dateien, die den Quellcode einer Anwendung speichern. ASP.NET stellt den Datenschutz dieser Dateien sicher, indem beiden Dateitypen System.Web.HttpForbiddenHandler zugeordnet wird. Dieser Handler gibt bei Aufruf eine Fehlermeldung an den Benutzer aus, der die Datei anfordert. Diese Methode kann in der Tat zur Einschränkung aller Dateitypen verwendet werden.
So ist z. B. auf microsoft.com site der Dateityp .asmx nicht erlaubt, was durch Einfügen des folgenden Eintrags im Abschnitt <system.web><httpHandlers> der Datei root web.config erreicht wird:
<add path="*.asmx" verb="*" type=
"System.Web.HttpForbiddenHandler" />
Sie können also die Subtags <Hinzufügen> im Element <httpHandlers> verwenden, um zusätzliche Dateitypen anzugeben, die geblockt werden sollen. Setzen Sie das Verbattribut gleich „*“. Dadurch wird angegeben, dass alle Typen von HTTP-Anfragen für diesen Dateityp gesperrt werden. Definieren Sie das Pfadattribut als Platzhalterzeichen, das den Dateitypen entspricht, die Sie blockieren möchten. So können Sie z. B. „*.mdb“ angeben. Setzen Sie abschließend das Typattribut auf System.Web.HttpForbiddenHandler.
4. Vorsicht beim Hinzufügen von Assemblyverweisen
Jeder Webserver, auf dem .NET Framework ausgeführt wird, verfügt über einen systemübergreifenden Codecache, den so genannten globalen Assemblycache (GAC). Im GAC werden Assemblys gespeichert, die ausdrücklich für andere Anwendungen auf dem Computer freigegeben sind. Es ist sinnvoll, dem GAC Assemblys hinzuzufügen, wenn mehrere unterschiedliche Anwendungen auf sie verweisen müssen, auch wenn der Großteil der Sites auf dem Webserver nicht auf sie zugreift. Dies führt nicht zu einem bedeutenden Leistungs- oder Ressourcenabfall, bietet jedoch den Vorteil der Verwaltung zentralisierter Versionssteuerung, statt freigegebener Assemblys, die sich über den gesamten Server in den /bin-Ordnern der einzelnen Anwendungen verteilen.
Die Kriterien für das Hinzufügen eines Assemblyverweises zur Datei root web.config sollten wesentlich strenger sein, als die Kriterien zum Hinzufügen einer Assembly zum GAC. Das Hinzufügen von Assemblyverweisen einzelner Anwendungen zu deren Datei web.config für Komponenten, die nicht wirklich global sind, führt zu einer wesentlich höheren Leistung als das Einfügen dieser Assemblyverweise in der Datei root web.config. Dadurch wird die Ladezeit für Seiten deutlich für Anwendungen auf einem Webserver reduziert, die diese Assemblys nicht verwenden, da der Compiler keine Zeit mehr damit zubringen muss, nicht erforderliche Assemblys zu laden. Der ASP.NET Compiler lädt eine Assembly dann nicht für eine Anwendung, wenn sich diese im GAC befindet. Er lädt die Assembly nur, wenn ein Assemblyverweis in der Anwendungsdomäne oder in einem höheren Anwendungsbereich vorhanden ist. Daher sind bei microsoft.com Entwickler dazu berechtigt, das Element <configuration><system.web><compilation><assemblies> in der Datei web.config ihrer Anwendungen für alle Microsoft.com-Umgebungen zu überschreiben.
Besonders in den Dateien root web.config der microsoft.com-Produktions- und Staging-Umgebungen sind alle Attribute des Knotens <system.web><compilation> gesperrt (einschließlich von debug, explicit, defaultLanguage) sowie deren Elemente (buildProviders, expressionBuilders u. a.), mit Ausnahme des Element <assemblies>:
<compilation debug="false"
explicit="true" defaultLanguage="vb"
numRecompilesBeforeAppRestart="500"
lockAttributes="*" lockAllElementsExcept=
"assemblies" >
In der intern ausgerichteten Präproduktionsumgebung ist der Bereich <system.web><compilation> in der Datei root web.config gesperrt, doch Anwendungsherausgeber sind dazu berechtigt, das Element <assemblies> und insbesondere das Element debug="false" zu überschreiben (um Fehlerbehebung/Debugging zu ermöglichen):
<compilation debug="false" explicit="true"
defaultLanguage="vb"
numRecompilesBeforeAppRestart="500"
lockAllAttributesExcept="debug"
lockAllElementsExcept="assemblies" >
Beachten Sie hierbei die Verwendung von Sperrattributen, die neu in ASP.NET 2.0 eingeführt wurden. Detaillierte Informationen zu diesen Attributen und Beispiele für deren Verwendung finden Sie unter Allgemeine von Abschnittselementen geerbte Attribute (möglicherweise in englischer Sprache).
5. Entfernen der manuell festgelegten MaxConnection-Werte
Nahezu alle microsoft.com-Websites verfügen über ASP.NET-Anwendungen, die Remote-Webservicecluster aufrufen. Die maximale Anzahl gleichzeitiger Remote-Webserviceaufrufe, die von einem Webserver getätigt werden können, wird über das Attribut maxConnection im Element <connectionManagement> in der Datei machine.config festgelegt. In ASP.NET 1.1 war der Wert für maxConnection standardmäßig auf 2 festgelegt. Dieser alte Standardwert für maxConnection war viel zu niedrig für Sites wie microsoft.com, die über Hunderte von unterschiedlichen Anwendungen verfügen, die Remote-Webserviceaufrufen durchführen. Dies führte dazu, dass ASP.NET-Anfragen in der Warteschlange blieben, bis die Remote-Webserviceaufrufe beendet wurden. (Die Anzahl der in der Warteschlange befindlichen ASP.NET-Anfragen kann über den perfmon-Zähler ASP.NET\Requests Queued angezeigt werden.) Der Wert für maxConnection wurde für unsere Webserver mit vier Prozessoren auf 40 erhöht, um mehrere gleichzeitige Aufrufe von Remote-Webservices zu ermöglichen (und somit die Leistung von Anwendungen auf der Site zu verbessern). (Der allgemein empfohlene Wert für maxConnection liegt bei der zwölffachen Anzahl von CPUs, dies kann jedoch in bestimmten Situationen angepasst werden.)
In ASP.NET 2.0 muss maxConnection nicht mehr manuell konfiguriert werden, da dieser Wert nun automatisch skaliert und eingestellt wird. Das ist das Ergebnis des neuen Konfigurationsbereichs für das Tag processModel in machine.config – weitere Informationen zum Element processModel finden Sie unter processModel-Element (Schema der ASP.NET-Einstellungen) (möglicherweise in englischer Sprache).
<system.web>
<processModel autoConfig="true" />
</system.web>
Wenn autoConfig in machine.config aktiviert ist (hierbei handelt es sich um die Standardeinstellung), setzt ASP.NET den Wert für den Parameter maxConnection auf 12n (wobei n die Anzahl der CPUs ist). Außerdem bewirkt die Aktivierung von autoConfig Folgendes: Die Parameter maxWorkerThreads und maxIoThreads werden auf 100 gesetzt, der Parameter minFreeThreads auf 88n, der Parameter minLocalRequestFreeThreads auf 76n und der Parameter minWorkerThreads auf 50.
Bevor Sie autoConfig in ASP.NET 2.0 verwenden, um die Werte für maxConnection und andere Attribute in der Liste automatisch zu skalieren und festzulegen, stellen Sie sicher, dass Sie manuell eingestellte Werte für diese Parameter entfernen, da diese Werte ansonsten statt der autoConfig-Werte verwendet werden. Denken Sie daran, wenn Sie von ASP.NET 1.1 (hier musste maxConnection ausdrücklich festgelegt werden) auf ASP.NET 2.0 migrieren (hier sind Standardwerte vorhanden).
Die autoConfig-Werte für maxConnection und die anderen aufgelisteten Attribute sind in gewisser Weise willkürlich und vielleicht nicht für jede Instanz geeignet, ich habe jedoch festgestellt, dass diese Werte für den Großteil der microsoft.com-Anwendungen geeignet sind.
Wenn Sie entscheiden, den Wert maxConnection manuell einzustellen, seien Sie vorsichtig, wenn Sie den Wert erhöhen, da dies zu einer höheren Auslastung der CPU führen kann. Dies ist darauf zurückzuführen, dass mehrere eingehende Anfragen von ASP.NET verarbeitet werden können, anstatt diese warten zu lassen, bis sie an die Reihe kommen, um den Webservice aufzurufen. Es sollte beachtet werden, dass sich das Attribut maxConnection lediglich auf Remoteaufrufe und nicht auf lokale Webserviceaufrufe bezieht.
6. Vermeiden von unbehandelten Ausnahmen
Bei der Portierung von ASP.NET 1.1-Websites oder -Anwendungen auf ASP.NET 2.0 ist es äußerst hilfreich, darauf zu achten, ob eine wichtige Änderung an der Standardrichtlinie für unbehandelte Ausnahmen vorgenommen wurde. In .NET Framework 1.1 und 1.0 wurden unbehandelte Ausnahmen auf verwalteten Threads ignoriert, und da die Anwendung weiterhin ausgeführt wurde, blieben diese Ausnahmen oft verborgen. Nur wenn ein Debugger angehängt wurde, um die Ausnahme zu erfassen, wurde Ihnen überhaupt bewusst, dass eine Ausnahme aufgetreten ist. Unter ASP.NET 2.0 wird die ASP.NET-basierte Anwendung jedoch unerwartet beendet, wenn eine unbehandelte Ausnahme eintritt. Dies kann sich ernsthaft auf Ihre Site oder die Anwendungsverfügbarkeit auswirken, wenn zahlreiche unbehandelte Ausnahmen auftreten, die zuvor bei der alten Richtlinie zur Handhabung von Ausnahmen verborgen blieben.
Die beste Lösungsmethode hier besteht in umfassenden Tests und im Eliminieren der unbehandelten Ausnahmen (die wirklich nicht in Ihrer Anwendung vorhanden sein sollten). Bei Migrationen sehr umfangreicher Anwendungen, bei denen es unter Umständen schwierig ist festzustellen, wo die Ausnahme aufgetreten ist, oder wenn Sie zahlreiche veraltete Anwendungen migrieren müssen, für die individuelle Tests nicht durchführbar sind, stehen Ihnen weitere Möglichkeiten zur Verfügung. Bei der Migration der microsoft.com-Website auf ASP.NET 2.0 haben wir die Regel für unbehandelte Ausnahmen auf die Standardeinstellung zurückversetzt, die in ASP.NET 1.1 und ASP.NET 1.0 angewendet wird.
Fügen Sie zum Aktivieren der Standardeinstellung für die Handhabung von Ausnahmen im veralteten System folgenden Code in der Datei aspnet.config hinzu:
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy
enabled="true" />
</runtime>
</configuration>
Der Code befindet sich in den folgenden zwei Ordnern:
%WINDIR%\Microsoft.NET\Framework\v2.0.50727 (auf x86 oder SYSWOW64-Systemen) und %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 (auf x64-Systemen).
Durch diese Änderung wird .NET Framework mehr oder weniger auf den Stand von 1.1 und 1.0 zurückversetzt. Betrachten Sie dies lediglich als kurzfristige Lösung, denn letztendlich handelt es sich hierbei nur um eine Verschleierung von Problemen in Ihrer Anwendung, bei denen es sich eigentlich um Fehler handelt. Es handelt sich hierbei jedoch um eine praktische Methode, Verfügbarkeitsprobleme aufgrund von unerwartet beendeten Arbeitsprozessen zu vermeiden. Weitere Informationen zu dieser Änderung finden Sie unter Unbehandelte Ausnahmen führen dazu, dass ASP.NET-basierte Anwendungen in .NET Framework 2.0 unerwartet beendet werden (möglicherweise in englischer Sprache).
7. Sicherstellen der ordnungsgemäßen Proxyserverkonfiguration
Webserveradministratoren können den Proxyserver festlegen, der für HTTP-Anfragen für das Internet verwendet werden soll, indem sie das Element <configuration><system.net><defaultProxy> in der Datei machine.config konfigurieren.
In der microsoft.com-Produktionsumgebung kann der Wert <defaultProxy> so konfiguriert werden, dass der Standardproxy des Systems verwendet wird (da der Firewallclient nicht installiert ist). Bei Microsoft werden die Tags <location allowOverride="false"> verwendet, um zu verhindern, dass das Element <defaultProxy> von Anwendungsentwicklern überschrieben werden kann (die unbeabsichtigt eine web.config-Datei auf einem internen Proxyserver veröffentlichen könnten):
<configuration>
<location allowOverride="false">
<system.net>
<defaultProxy>
<proxy usesystemdefault="true" />
</defaultProxy>
</system.net>
</location>
</configuration>
In den internen Präproduktions- und Staging-Umgebungen von microsoft.com wird das Attribut "usesystemdefault" auf "False" und "bypassonlocal" auf "True" gesetzt sowie eine Proxyumgehungsliste hinzugefügt (siehe Abbildung 2). In der Umgehungsliste werden übliche Ausdrücke aufgeführt, die Adressen beschreiben, die nicht den angegebenen Proxyserver verwenden. Dieser Abschnitt befindet sich in den Tags <location allowOverride="false">, um zu verhindern, dass Entwickler in den web.config-Dateien ihren eigenen Proxyserver angeben. (Bei diesen Proxyservern handelt es sich häufig um interne Server, und Aufrufe des Servers werden oft unterbrochen, wenn die Seiten auf dem Produktionsserver veröffentlicht werden.) Ein Versuch, einen Proxyserver in einer Präproduktions- oder Staging-Umgebung festzulegen, führt zu einem ASP.NET-Laufzeitfehler, der Entwickler dazu zwingt, diese Konfiguration vor der Produktionsveröffentlichung zu entfernen.
Figure 2 Einrichten von Umgehungslisten
<configuration>
<location allowOverride="false">
<system.net>
<defaultProxy>
<proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />
<bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
</bypasslist>
</defaultProxy>
</system.net>
</location>
</configuration>
8. Benutzerspezifische Fehler nicht wahllos anzeigen
Wie bereits erwähnt ist es besonders wichtig, die Remote-Rückgabe detaillierter ASP.NET-Fehlermeldungen von Webservern in der Produktionsumgebung nicht zuzulassen.
In den root web.config-Dateien der microsoft.com-Produktions- und Staging-Umgebungen ist das Modusattribut <configuration><system.web><customErrors> auf RemoteOnly gesetzt, was dazu führt, dass benutzerspezifische Fehler auf Remoteclients und ASP.NET-Fehler auf dem localhost-Server angezeigt werden (um die Fehlerbehebung durch Webserveradministratoren zu ermöglichen). Beachten Sie, dass das Element <customErrors> in einem <location>-Tag enthalten ist, wobei allowOverride="false" gilt (siehe Abbildung 3). Dies wurde eingerichtet, um zu verhindern, dass individuelle Anwendungseigentümer unbeabsichtigt (oder absichtlich) die Einstellung mode="Off" vornehmen und detaillierte ASP.NET-Fehlermeldungen so in das Internet gelangen.
Figure 3 Verhindern der Anzeige von Fehlermeldungen
<configuration>
<location allowOverride='false'>
<system.web>
<customErrors mode='RemoteOnly' defaultRedirect=
'/errorpages/generic_customerror.aspx'>
<error statusCode='404' redirect='/errorpages/filenotfound_customerror.aspx' />
</customErrors>
</system.web>
</location>
<configuration>
Beachten Sie auch, dass, wie zuvor angeführt, die Verwendung des Schalters <deployment retail="true"/> in der Datei machine.config die Option zur Anzeige detaillierter ASP.NET-Fehlermeldungen sowohl auf Remoteclients- als auch auf lokalen Servern ausschaltet. Wenn Sie ASP.NET 2.0 ausführen, sollten Sie diesen Bereitstellungsverkaufsschalter als Methode zum Ausschalten dieser Fehlermeldungen bevorzugen. (Detaillierte Informationen zu ASP.NET-Ausnahmen finden Sie im Anwendungsereignisprotokoll.)
In der intern ausgerichteten microsoft.com-Präproduktionsumgebung ist in der Datei root web.config das Modusattribut <customErrors> auf Off gesetzt, sodass ASP.NET-Fehler immer auf dem localhost-Server und den Remoteclients angezeigt werden. Hierdurch wird Debugging und Fehlerbehebung ermöglicht. Darüber hinaus werden keine benutzerspezifischen Fehlerseiten konfiguriert:
<configuration>
<location allowOverride="false">
<system.web>
<customErrors mode="Off" />
</system.web>
</location>
<configuration>
9. Wissen, wann Ablaufverfolgung aktiviert werden sollte
ASP.NET-Ablaufverfolgungen werden während der Ausführung einer ASP.NET-Seite generiert und erfassen interessante Details zu Webanfragen, Verzeichnissen von Seitensteuerelementen sowie die Ausführung unterschiedlicher Stadien des Seitenlebenszyklus und der Steuerelemente. Darüber hinaus können benutzerspezifische Nachrichten, die vom Seitenentwickler in die Ablaufverfolgung eingetragen werden können, angezeigt werden. Die Ablaufverfolgung kann der Antwortausgabe für die Seite angehängt werden, für die die Ablaufverfolgung erstellt wird, oder als Teil der Liste für Anfragen mit Ablaufverfolgung im Ablaufverfolgungs-Viewer für die Anwendung angezeigt werden. Die Funktion ist vorwiegend für Debuggingsituationen während der Entwicklungsphase in internen Präproduktionsumgebungen vorgesehen und sollte nicht in Produktionsumgebungen verwendet werden.
In den microsoft.com-Produktions- und Staging-Umgebungen ist in den Dateien root web.config das aktivierte Attribut <configuration><system.web><trace> auf „False“ gesetzt, sodass die Ausgabe von Ablaufverfolgungsinformationen auf einer Webseite deaktiviert ist. Beachten Sie, dass das Element <trace> sich in dem Tag <location> befindet, wobei Folgendes gilt: allowOverride="false". Dies wurde eingerichtet, um zu verhindern, dass individuelle Anwendungseigentümer unbeabsichtigt (oder absichtlich) die Einstellung enabled="true" und somit detaillierte ASP.NET-Ablaufverfolgungsinformationen in das Internet gelangen:
<configuration>
<location allowOverride="false">
<system.web>
<trace enabled="false" localOnly="true"
pageOutput="false" requestLimit="10" traceMode="SortByTime" />
</system.web>
</location>
<configuration>
<system.web><trace>
Die Verwendung des Schalters <deployment retail="true"/> in der Datei machine.config schaltet die Ausgabe von ASP.NET-Verfolgungsinformationen auf einer Website ebenso aus. Bei diesem Schalter sollte es sich um die bevorzugte Methode zum Ausschalten der Ablaufverfolgungsausgabe handeln, wenn Sie .NET Framework 2.0 ausführen.
Um absolut sicherzustellen, dass die Ausgabe von Ablaufverfolgungen nicht unbeabsichtigt in nach außen gerichteten Produktionsumgebungen aktiviert werden können, wird bei microsoft.com der eigentliche trace.axd-Handler aus der Datei root web.config entfernt oder mithilfe eines Kommentars deaktiviert:
<!--
<add path="trace.axd" verb="*" type=
"System.Web.Handlers.TraceHandler"
validate="True" />
-->
10. Deaktivieren des Sitzungsstatus für Webfarmen
Da alle Websites auf microsoft.com derzeit über einen Netzwerklastenausgleich (Network Load Balancing, NLB) ohne Affinität (um eine gleichmäßige Verteilung der Anfragen über alle Server im Cluster zu erlauben) gruppiert sind, gibt es keine Garantie, dass alle Anfragen für eine Anwendung von dem gleichen Server abgearbeitet werden. Aus diesem Grund ist das ASP.NET-Sitzungsstatusmodul deaktiviert, um die Verwendung der Eigenschaft „Sitzung“ von Anwendungsentwicklern zu verhindern. Als Richtlinie für Anwendungsentwickler, die den Status verwalten müssen, weisen wir diese an, „Ansichtszustand“ zu verwenden (dadurch wird der Status in einer Struktur im Seitencode verwaltet, und daher werden keine Serverressourcen beansprucht).
Zum Deaktivieren des Sitzungsstatus auf einem Webserver kann einfach folgender untergeordneter Knoten aus dem Knoten <httpModules> entfernt werden:
<add name="Session" type=
"System.Web.SessionState.
SessionStateModule"/>
In diesem Artikel wird davon ausgegangen, dass Sie bereits mit ASP.NET-Konfigurationdateien (machine.config, root web.config und einzelnen web.config-Anwendungsdateien) gearbeitet haben. Falls dies nicht der Fall ist, finden Sie in folgendem ASP.NET-Lernprogramm zum Schnellstart hilfreiche Informationen: asp.net/QuickStart/aspnet/doc/management/fileformat.aspx.
In dem Artikel wird erwähnt, dass das ASP.NET 2.0-Konfigurationssystem nun über eine Reihe von nützlichen Funktionen verfügt, mit denen Administratoren einzelne Elemente und Attribute der Konfiguration mithilfe der Attribute lockItems und lockCollections sperren können. Informationen zu diesen Attributen und deren Verwendung finden Sie in folgendem Artikel: Allgemeine Attribute, die von Abschnittselementen geerbt wurden (möglicherweise in englischer Sprache).
Jeff Toews, Systemtechnikmanager, ist seit sechs Jahren Mitglied des Microsoft.com-Betriebsteams mit Sitz in Redmond, WA. Sie können ihn bei technischen Fragen oder Kommentaren unter mscomblg@microsoft.com erreichen.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.