Over Atos Origin
Contact
Diensten
Nieuws
Home
Feedback  |  Atos Origin.com  |  Syndicatie
Syndicatie
 
Links
Archief
Meer over de bloggers
Onderwerpen
Alle onderwerpen
Agile
Algemeen
Architectuur
Besturingssystemen
Bpm
Business intelligence
Business proces design
Cloud computing
Eai
Governance
Ibm
Integratie
It consultancy
Java
Microsoft
Nljug
Open source
Oracle
Process standaarden
Project management
Requirements engineering
Rich internet applications
Saas
Security
Sharepoint
Soa
Testing
Virtualisatie
Xml

Web.Config Slice-And-Dice
Geplaatst op 1 November 2008, 13:59 door Sander van de Velde in microsoft, xml, algemeen

 

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.


Share this | 922 keer bekeken | 3 reacties
Reacties Syndicatie en RSS

Mark Lammerse reageert, op November 6, 2008 om 10:23 (GMT +01:00):

Het belangrijkste aspect aan web.config files is dat het niet het middel is om een website te configureren, maar alleen de oplossing..  dat behoeft uitleg:

Dus je hebt een website met een database erachter. Daarvoor gebruik je als goede ontwikkelaar dus een laag van objecten die requests van de interface vertalen naar objecten in de database. Ongeacht het abstractieniveau zul je dus minimaal een component moeten hebben die die database moet kunnen vinden en moet aantonen dat die de db mag gebruiken en heeft dus een connectionstring nodig. En die staat meestal in de web.config. Zover niets nieuws..

Wellicht wel nieuw is dat een goede oplossing een installer heeft van dat datalaag-component en dat component zorgt zelf voor de juiste bewerkingen in de web.config.. tijdens installatie, de-installatie en wellicht zelfs configuratie.

Voor een kleine simpele website wellicht overkill, maar daar zijn web.config bestanden ook klein en simpel/overzichtelijk.
Een Sharepointsite met een aantal custom solutions en een aantal webparts; ononkoombaar, tenzij je met gigantische last wilt komen te zitten van configuratie en management.

Het is dus aan te bevelen iig te onderzoeken welke delen van de web.config wel en welke niet handmatig mogen worden bewerkt, en deze als zodanig op te delen. Maar in het algemeen is het zo dat als je een web.config handmatig moet aanpassen als je een nieuwe versie installeert van je datacomponent of ander component in je website, er eigenlijk iets mis is.


Heindirk de Laat reageert, op November 7, 2008 om 08:20 (GMT +01:00):

Mark, wat bieden Microsoft of anderen voor oplossing om tijdens de installatie configfiles aan te passen? En hoe doe je dat als je meer omgevingen hebt (ontwikkel, test, acceptatie, productie)?



Marco Pankow reageert, op December 16, 2008 om 10:31 (GMT +01:00):

Goed en duidelijk verhaal, Sander.

Thanks.


Reageer
 
 
Top artikelen
  • J-Spring 2009:Hop on board the Java Troubleshooting Platform
  • Softwaredocumentatie met Sandcastle
  • Agile Springboard
  • Blik op kwaliteit door middel van Six Sigma
  • Developers zijn kikkers
Recente reacties
  • IDC voorspelt dat SaaS mainstream wordt binnen paar ...
  • PrimeFaces is nauwelijks nog bekend terwijl het veel ...
  • Dank!
  • Het bijwerken is met behulp van if(contains()) remove() ...
  • Alleen keuren de bovengenoemde alternatieven duplicate entries af ...
  • Terms of use
  • Legal