Konfigurační parametry aplikace v ASP.NET

Pravděpodobně jste se při tvorbě web aplikací už potýkali s problémem, kam uložit konfiguraci aplikace. Dnes se dozvíte, jak tento problém vyřešit v aplikacích psaných v ASP.NET.

Představte si situaci, kdy vytvoříte aplikaci s řadou vstupních parametrů (například connection string do databáze), které je třeba čas od času změnit. Pokud parametry „nacpete“ přímo do zdrojových kódů, čeká vás nutnost opravit několik řádků kódu často i v několika souborech a opětovné přeložení aplikace. Bohužel se občas nevyhnete zanesení chyb do aplikace při těchto úpravách.

Také se vám tento postup nelíbí stejně jako mně? Pokusím se vám tedy předvést, jak se takovéto zapeklité situaci vyhnout. Jak již víte například z  článku „soubor web.config“, existuje v prostředí .NET Frameworku soubor web.config, který je pro takové účely přímo předurčen.

Po standardní instalaci .Net Frameworku jsou soubory .config pro návštěvníky nepřístupné. Pokud si úmyslně toto nastavení nezměníte, jsou informace uložené v souboru web.config relativně v bezpečí. Ovšem za předpokladu, že máte web server zabezpečen. V případě „děravého“ serveru nelze, kromě toho, že si útočník díry nevšimne, spoléhat vůbec na nic. Ovšem spoléhat na to, že si špatného zabezpečení nikdo nevšimne, není ten správný přístup ke správě serveru.

Standardně je možné do souboru web.config umístit sekci appSettings, do které můžete umisťovat jednotlivé položky konfiguračních parametrů své aplikace.

<appSettings>
    <add key=“conn_DB“ value=“user id=sa;password=heslo;initial catalog=interval;data source=localhost;Connect Timeout=30″ />
</appSettings>

A následné přečtení údajů provádět pomocí konstrukce

string Constring=ConfigurationSettings.AppSettings[„conn_DB“]

Nyní již můžete s proměnnou Constring pracovat tak, jak jste zvyklí, a použít ji k vytvoření spojení do databáze (v tomto případě do MS SQL serveru).

Co však dělat v případě, kdy je vytvářená aplikace velmi rozsáhlá a na jednotlivých funkčních celcích pracují dokonce i různí lidé. I tento problém lze snadno vyřešit přímo v souboru web.config. Stačí pouze nadefinovat vlastní sekci pomocí následující konstrukce vložené do tagu configSection.

<section name=“MojeSekce“ type=“System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

Výše uvedená konstrukce platí pro .NET Framework 1.0. Při použítí .NET Frameworku 1.1. budou definice vlastní sekce vypadat takto:

<section name=“MojeSekce“ type=“System.Configuration.NameValueFileSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

Do takto nadefinované sekce se budou již zapisovat klíče stejně jako appSettings. Použití vlastní definované sekce pak bude vypadat zhruba takto:

<configSections>
<section name=“MojeSekce“ type=“System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />
</configSections>

<MojeSekce>
    <add key=“conn_DB“ value=“user id=sa;password=heslo;initial catalog=interval;data source=localhost;Connect Timeout=30″ />
</MojeSekce>

Údaje uložené v uživatelsky definované sekci poté načtete pomocí metody GetConfig a pak již načtený údaj používáte podle libosti.

string Constring=ConfigurationSettings.GetConfig(„MojeSekce“)(„conn_DB“)

Závěrem si jen dovolím trochu odbočit a připomenout velice důležitou věc, dbejte na precizní zabezpečení serveru a stav zabezpečení pravidelně kontrolujte. Pouze dobře zabezpečený server ochrání vaše data. Pro získání informací o zabezpečování serverů a stanic na platformě Microsoft si vás dovolují odkázat na Microsoft TechNet. Najdete zde nejenom všechny vydané záplaty, ale i velké množství nástrojů pro kontrolu stavu zabezpečení a množství postupů jak vůbec vlastní zabezpečování provádět. Pro ty z vás kteří nevládnou tak dobře angličtinou, zde mám tip na český překlad knihy Bezpečnost Windows 2000/XP, kde jsou popisována bezpečnostní rizika i postupy, jak se jim bránit.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.