Web.Config Slice-And-Dice

De web.config is de standaard oplossing voor het configureren van de asp.net
websites. Zowel instellingen van ASP.Net zelf als door de ontwikkelaar gekozen
configuratie-instellingen kunnen daarin opgeslagen worden.

Standaard wordt de web.config bijgewerkt door de ontwikkelaar waarna bij het opleveren van de website, door middel van een installatiehandleiding, aangegeven wordt welke instellingen achteraf nog aangepast moeten worden zoals afwijkende paden voor bestanden of ander connectionstrings.

Eigenlijk is dit pesten van systeembeheers. Iedere ontwikkelaar die wel eens in de web.config heeft gekeken, weet dat er ontzettend veel risico’s aan het wijzigen van configuratiebestanden hangen. Zelf hebben we ook een hekel aan die onleesbare XML oprisping. Een onbedoelde verminking is zo gemaakt en dan gaat de site gewoon op zwart met de meest uiteenlopende, vaak nietszeggende foutmeldingen.

Toch is dit risico redelijk te beperken zonder extra moeite voor de ontwikkelaar. Sterker nog, ook voor hen is er een voordeeltje te halen. Het is namelijk minder bekend dat we als een japanse chefkok de web.config gewoon in aparte bestanden kunnen opsnijden zodat de lengte ervan aanzienlijk vermindert.

Stel, je hebt een web.config:

<?xml version="1.0"?>
<configuration>
  . . . . .
  <appSettings>
    <add key="sleutel" value="tekst" />
  </appSettings>
</configuration>

In dit voorbeeld kun je de appSettings vast wel terugvinden maar een gemiddelde web.config zal eerder enkele honderden regels aan XML elementen
bevatten en dat is een stuk minder overzichtelijk.

De oplossing is dan om de application settings sectie te verhuizen naar een
apart bestand en deze te benoemen als config source in de oorspronkelijke
web.config sectie:

<?xml version="1.0"?>
<configuration>
  . . . . .
  <appSettings configSource="config\web.appsettings.config" />
</configuration>

Hier is het aparte bestand met de veelzeggende naam ‘web.appsettings.config’
in een map, genaamd ‘config’, geplaatst. In dat bestand staat dan de uiteindelijke appSettings sectie, dus zonder de configuration omarming etc.

<appSettings>
  <add key="sleutel" value="tekst" />
</appSettings>

Bij het starten van de website wordt de web.config samengevoegd met alle
gerefereerde bestanden. Er is dus voor de rest geen verschil tussen het
originele configuratiebestand en de combinatie van al die configuratiebestanden.
Sterker nog, tooling zoals de Asp.NET Configuration website ( Menu | Website |
ASP.NET Configuration) blijven gewoon werken met deze situatie en schrijven ook gewoon in de aparte bestanden.

Secties kunnen ook versleuteld worden zodat de inhoud niet meer te lezen is.
De inhoud van een sectie wordt in de web.config gesleuteld. Kijk voor een prima
uitleg op de site van 4 guys from Rolla. Dit werkt dus ook nog steeds bij een sectie in een apart bestand. Hier is een voorbeeld van de connectionstring sectie buiten de web.config:

<connectionStrings configProtectionProvider="
                             DataProtectionConfigurationProvider">
  <EncryptedData>
    <CipherData>
      <CipherValue>AQAAAN [knip] tVZEu</CipherValue>
    </CipherData>
  </EncryptedData>
</connectionStrings>

Een dergelijke versleuteling is dus perfect als in de connectionstring bv.
gevoelige informatie zoals een inlognaam of wachtwoord staat. Deze informatie is dus niet meer leesbaar hoewel ontsleutelen wel mogelijk blijft, afhankelijk van
de gekozen versleutelmethode. Bijkomstig voordeel is dat hier dus simpel
bestanden vervangen kunnen worden, bv. bij gebruik van een machine afhankelijke versleuteling.

De tweede sectie en volgende secties moeten allen in apart bestanden
ondergebracht worden. Verschillende secties kunnen niet samen ondergebracht
worden in een enkel bestand. Dit kan je tot de verleiding brengen om alle
mogelijke secties te verhuizen naar aparte bestanden.

Ik heb hier de complete web.config van een nieuw Asp.NET project
teruggebracht tot nog maar enkele regels XML door secties te verplaatsen. De
overige heb ik verwijderd en de applicatie start nog gewoon op:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <compilation configSource="config\web.compilation.config" />
    <authentication configSource="config\web.authentication.config" />
    <customErrors configSource="config\web.customErrors.config" />
    <pages configSource="config\web.pages.config" />
    <httpHandlers configSource="config\web.httpHandlers.config" />
    <httpModules configSource="config\web.httpModules.config" />
  </system.web>
  <system.codedom configSource="config\web.system.codedom.config" />
  <appSettings configSource="config\web.appSettings.config" />
  <connectionStrings configSource="config\web.connectionStrings.config" />
</configuration>

Niet iedere sectie kan zondermeer verhuisd worden maar dit ruimt wel lekker op 🙂

Nu kun je dus de keuze maken om werkelijk alle secties in aparte bestanden onder te brengen zodat eventuele wijzigingen verdeeld worden over verschillende bestanden of om allen statische instellingen te verhuizen en de
wijzigingen te verzamelen in de web.config. De laatste optie spreekt mij het
meeste aan. Het ging er aan het begin van dit verhaal vooral om dat
systeembeheer tegen zichzelf beschermd kan worden en dat de te onderhouden
instellingen weer overzichtelijk worden. Laat de te onderhouden settings dus
gewoon in de web.config en verhuis de rest.

Advertenties