|
|
|
|
|
Web.Config 101
Geschrieben von: Christian Holm Die web.config Datei ist eine auf XML basierende, hierarchisch aufgebaute Textdatei die eine Vielzahl von Einstellungsmöglichkeiten für Ihre ASP.NET Applikationen erlaubt. Angefangen von Applikationseinstellungen, über DSN bis hin zu Optionen für Web Services. Der hierachische Aufbau erlaubt eine übersichtliche Gliederung und somit wird die Anpassung der web.config zum Kinderspiel. Daß dies nicht nur ein Marketingschlagwort ist, soll dieser Einführungsartikel zeigen. Die web.config ist zusammen mit der machine.config das Herzstück jeder ASP.NET Applikation. Die machine.config ist dabei die Hauptkonfigurationsdatei von der sich alle anderen ASP.NET Konfigurationsdateien ableiten. Daher existiert die machine.config auch nur einmal auf dem Computer. Diese enthält die standardmäßigen Einstellungen für den jeweiligen Computer. Die web.config, welche sich wie vorher schon erwähnt von der machine.config ableitet, kann je nach Bedarf beliebig oft auf dem ASP.NET Webserver existieren. Das bedeutet, Sie können für jede ASP.NET Applikation eine speziell angepaßte Konfigurationsdatei erstellen, da ASP.NET während der Laufzeit nach diesen Dateien sucht und die enthaltenen Einstellungen für jedes Verzeichnis extra und unabhängig parst. Die hierachische Ableitung erfolgt von der ASP.NET Hauptkonfigurationsdatei (machine.config) bis in die einzelnen virtuellen Verzeichnisse jeder einzelnen am .NET Webserver befindlichen Applikation. Bildlich gesprochen sieht dies für einen Beispiel-.NET Webserver so aus: 
Natürlich könnte z.B. die MyWebApp1 auch in einem anderen physikalischen Pfad liegen. Beachten Sie, daß die Erstellung der web.config optional ist, d.h. wenn in einem Verzeichnis keine vorhanden ist, so werden die Einstellungen der übergeordneten Ebene verwendet. Die ASP.NET Runtime arbeitet diese Struktur bei einem URL Request ab. Natürlich wird dies nur einmal ausgeführt, da diese Einstellungen nach dem ersten Request im Cache abgelegt werden. Damit Änderungen nach dem ersten Durchlauf berücksichtigt werden können, setzt die ASP.NET Runtime einen Filewatcher auf diese Dateien und aktualisiert die gecacheten Dateien falls erforderlich. Da die web.config auf XML basiert, kann diese auch XML Dokumentelemte enthalten, also auch neben den obligaten well-formed Tags auch Kommentare oder CData Sektionen. Die Codierung der Datei ist hierbei unwesentlich da ASP.NET diese automatisch erkennt und anpaßt. Die Codierung muß lediglich einem der gängigen Standards (z.B. UTF-8 oder Unicode) entsprechen. Was kann die web.config nun alles enthalten? Dies ist eine ganze Menge: Applikationeinstellungen, sicherheitssensitive Einstellungen (Authentifikation und Autorisierung von Usern), Datenbankverbindungseinstellungen, Browsereinstellungen, Debugeinstellungen, Einstellungen für ASP.NET Web Services und mehr. Alle diese Einstellungen sind übersichtlich in einzelne Sektionen unterteilt. Die web.config besitzt ein Hauptelement oder Tag - <configuration>. Dieser Tag kann drei unterschiedliche Elementtypen enthalten, welche innerhalb des <configuration>-Tags geschachtelt werden:
Bevor ich Ihnen eine Übersicht über die möglichen ASP.NET Section Handlers gebe, noch eine Anmerkung zum Casing in der web.config. Abgesehen davon, daß die XML Tags well-formed sein müssen, haben die Tags, Attributnamen und ihre Werte eine strikte Schreibweise:
Nun eine Übersicht zu den ASP.NET Section Handlern:
Abschließend möchte ich noch auf ein paar Section Handlers mit einem Beispiel näher eingehen. Beginnen wir mit den <appSettings>. Diese könnte man in einer Beispiel web.config so verwenden, um einen DSN einer ASP.NET Site zur Verfügung zu stellen:
<configuration>
<system.web>
<appSettings>
<add key="Northwind" value="server=(local)\NetSDK;database=Northwind;Trusted_Connection=yes;" />
</appSettings>
</system.web>
</configuration>
Um dann diesen DSN in einer ASP.NET Seite nützen zu können, ist zusätzlich der System.Configuration Namspace einzubinden, und folgender Code zu verwenden (siehe Beispiel). In diesem Beispiel baue ich die Verbindung mittels dem SqlDataAdapter auf und gehe wie gewohnt vor (der Einfachheit halber habe ich nur den serverseitigen Scriptblock angeführt):
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<%@ Import Namespace="System.Configuration" %>
<html>
<script language="C#" runat="server">
void Page_Load(Object Src, EventArgs E ) {
String MyDSN = ConfigurationSettings.AppSettings["Northwind"];
SqlConnection myConnection = new SqlConnection(MyDSN);
SqlDataAdapter myCommand = new SqlDataAdapter("SELECT * FROM Products", myConnection);
DataSet ds = new DataSet();
myCommand.Fill(ds, "Products");
MyDataGrid.DataSource=new DataView(ds.Tables[0]);
MyDataGrid.DataBind();
}
</script>
Weiters möchte ich ein Beispiel für den <authentication> Section Handler geben. Wie in der Gegenüberstellung schon erwähnt, kann man hiermit eine Formular-basierde Authentifikation realisieren. Der folgende Ausschnitt aus einer web.config soll die notwendigen Einstellungen verdeutlichen:
<configuration>
<system.web>
<authentication mode="Forms">
<forms name="lg000" loginUrl="admin/Login/login.aspx"
protection="All" timeout="20" path="/" >
<credentials passwordFormat="MD5">
<user name="JDoe" password="nevergiveupneversurrender" />
</credentials>
</forms>
</authentication>
</system.web>
</configuration>
<authentication mode> setzt den Authentication Modus und ist hier auf Formular-basierend gesetzt. Dieser kann aber auch auf Windows Authentication, Microsoft Passport oder auf Anonym (None) gesetzt werden. Der <forms> Tag enthält den Namen des Cookies (lg000), der für die Authentifizierung verwendet werden soll; den Redirect auf jene Seite, wenn der Login fehlschlägt (admin/Login/login.aspx); und die Sicherheitsstufe, wie der Cookie geschützt werden soll. Andere gültige Einstellungen sind noch Encryption, Validation oder None. Zusätzlich kann man noch einen Timeout (in Minuten) angeben, wann der Cookie abläuft, sowie den Pfad wo sich der Cookie befindet. Unter <credentials> können die Credentials für die User eingetragen werden. Stattdessen kann aber auch eine Datenbankquelle für die einzelnen User angegeben werden (ist irgendwie bequemer). Wie Sie durch das obige Beispiel sicherlich erkannt haben, können in der web.config auch Sicherheits-sensitive Daten als Klartext angeführt sein. Aus diesem Grund konfiguriert ASP.NET den IIS, daß ein Browser auf Dateien mit der Endung .config nicht direkt zugreifen kann und somit nicht in falsche Hände kommt. Wer es dennoch versucht, erhält folgenden Fehler: 
SchlußbemerkungDies war ein kurzer Überblick über die Mächtigkeit der Einstellungen in der web.config. Durch die einfache Handhabung der XML basierten Datei ist die Konfigurierung und Absicherung von ASP.NET Applikationen sehr einfach und läßt kaum Wünsche offen. Download des CodesKlicken Sie hier, um den Download zu starten. Verwandte Artikel
Datenbankzugriff mittels ADO.NET Wenn Sie jetzt Fragen haben...Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.
Eine weitere sehr hilfreiche Resource ist das deutsche ASP.NET Wiki, das als zentrale Anlaufstelle für Tips, Tricks, Know How und alles Nützliche was man in seinem Alltag als (ASP).NET-Entwickler so braucht und entdeckt gedacht ist. Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.
Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.
©2000-2006 AspHeute.com |
