[ASP.NET] Uitlezen web.config

[Verwijderd]

Beste tweakers,

Op de een of andere manier moet ik in de web-server bij de provider een andere connectionstring gebruiken dan dat ik thuis lokaal ontwikkel. Lokaal moet ik Driver={MySQL ODBC 3.51 Driver} gebruiken en bij de provider Driver={MySQL}.

Nou dacht ik dit afhankelijk te maken van de DEBUG tag in de COMPILATION setting van de web.config. Als deze true is ben ik lokaal aan het ontwikkelen en bij de provider staat dit altijd op false.

Het lukt mij alleen niet om deze waarde uit te lezen. Ik zie wel 10000000 mogelijkheden om iets uit een eigen toegevoegde custom tag uit te lezen, of om uit de appSettings tag iets uit te lezen, maar geen een mogelijkheid om uit de <configuration>\<System.web>\<compilation> tag het debug attribuut uit te lezen.

Ik hoop dat iemand dit al eens heb gedaan. Ik ben het helaas nog niet tegengekomen.

[whoami]

Kijk hier eens:
[rml][ ASP.NET] Webdev tips[/rml]
Waar connectionstrings opslaan in .NET

Dit staat werkelijk in de MSDN en in veel tutorials/quickstarts uitgelegd. De connectionstring lees je dan als volgt uit:

code:

string connstr = ConfigurationSettings.AppSettings["myKeySpul"].ToString();

Als je je project uploaded, verander je gewoon de connectionstring oid. Of je maakt 2 entries in je appSettings; en je veranderd de key voordat je uploaded.

[ Voor 16% gewijzigd door whoami op 25-04-2004 11:45 ]

[whoami]

Kan je trouwens niet iets met de conditional defines gaan doen?

code:

#if DEBUG
    // haal lokale connection-string op
#else
   // haal connectionstring voor provider op.
#endif

[gorgi_19]

Volgens mij wil je dit niet met conditional code gaan oplossen; connectionstring in de web.config lijkt me de enige nette oplossing. Voor de rest veranderd er wel meer in je web.config dan alleen in connectionstring als je aan het debuggen / dev'en bent t.o.v. productie. Neem bijvoorbeeld tracing.

[Verwijderd]

whoami schreef op 25 april 2004 @ 11:44:
Kijk hier eens:
[rml][ ASP.NET] Webdev tips[/rml]
Waar connectionstrings opslaan in .NET

Dit staat werkelijk in de MSDN en in veel tutorials/quickstarts uitgelegd. De connectionstring lees je dan als volgt uit:

code:

string connstr = ConfigurationSettings.AppSettings["myKeySpul"].ToString();

Als je je project uploaded, verander je gewoon de connectionstring oid. Of je maakt 2 entries in je appSettings; en je veranderd de key voordat je uploaded.

Nee, helaas, dat is weer met die APPSETTINGS. Dat staat inderdaad wel 100000 keer overal uitgelegd, maar zoek ik dus niet. Ik wil de DEBUG setting uit web.config uitlezen. Voor zover ik heb geprobeerd lukt dat niet met ConfigurationSettings.AppSettings.

Ik ben er een beetje op tegen om mijn connectionstring in de web.config te plaatsen omdat deze gewoon als plain text is in te lezen. We hebben een data, busines en User interface component. De connectionstring staat gewoon hard in de datalaag DLL. Deze moet dus uitvinden of de web.config DEBUG switch true of false is. Dat laatste krijg ik nu helaas nog steeds niet voor elkaar.

[gorgi_19]

Ik ben er een beetje op tegen om mijn connectionstring in de web.config te plaatsen omdat deze gewoon als plain text is in te lezen. We hebben een data, busines en User interface component. De connectionstring staat gewoon hard in de datalaag DLL. Deze moet dus uitvinden of de web.config DEBUG switch true of false is.

Als dat het enige is, maak je toch een eigen encrypty en decryptie functie voor je connectionstring?

Ik gok trouwens ook dat je de veiligheid van een compiled assembly te hoog inschat. Het is en blijft nog steeds kinderlijk eenvoudig om hier gegevens uit te halen. Gebruik maar eens deze decompiler (Bron: http://www.asp.net/Forums...x?tabindex=1&PostID=16847)

Maar goed, wil je een oplossing hebben, dan is de tweede oplossing van whoami de oplossing die je zoekt. De kijkt trouwens niet naar de web.config, maar in welke mode Visual Studio de assemblu compiled (release build of debug build)

En anders: een web.config is niets anders dan een xml-bestand, welke je rustig kan uitlezen en evt. met XPath kan behandelen.

[ Voor 25% gewijzigd door gorgi_19 op 25-04-2004 17:23 ]

[whoami]

Als je een ASP.NET web-app hebt, dan is het onmogelijk dat gebruikers aan die web.config kunnen.
Daarnaast is het even onveilig als je de connectie-string (niet ge-encrypted) in de assembly zelf zet: met een simpele hex-editor kan je hem er zo uithalen.
Daarnaast heb je nog een probleem als je die connectiestring in de code zet: als je connectie-string veranderd, moet je je app hercompileren en opnieuw deployen.

[CaptBiele]

whoami schreef op 25 april 2004 @ 22:19:
Als je een ASP.NET web-app hebt, dan is het onmogelijk dat gebruikers aan die web.config kunnen.
Daarnaast is het even onveilig als je de connectie-string (niet ge-encrypted) in de assembly zelf zet: met een simpele hex-editor kan je hem er zo uithalen.
Daarnaast heb je nog een probleem als je die connectiestring in de code zet: als je connectie-string veranderd, moet je je app hercompileren en opnieuw deployen.

Is het echt ONMOGELIJK om aan web.config te komen? waarom zijn er dan zoveel voorstellen om nog de conn string te encrypten decrypten, zoals hier?
Is dat dan alleen om de string te beschermen tegen de beheerders die lokaal op de server kunnen oid? lijkt me niet toch?

[gorgi_19]

CaptBiele schreef op 26 april 2004 @ 04:14:
Is het echt ONMOGELIJK om aan web.config te komen? waarom zijn er dan zoveel voorstellen om nog de conn string te encrypten decrypten, zoals hier?
Is dat dan alleen om de string te beschermen tegen de beheerders die lokaal op de server kunnen oid? lijkt me niet toch?

Ja, 't is een gevoelskwestie. Verder als een server admin IIS loopt te vernaggelen, dan is de web.config wel opvraagbaar (normaliter niet en dan moet hij hem wel heel goed (bijna bewust) vernaggelen).

Alleen om de boel om bovengenoemde reden maar compiled in een assembly te stoppen, is even nutteloos. Een paar posts erboven heb ik al aangegeven (en whoami ook) dat je met even zoeken die connectionstring ook zo achterhaald hebt.
Ik vraag me zelfs af of obfuscation in dit geval ook nog gaat helpen.

Sowieso kan je anders een ander account maken voor de webserver, welke minder rechten heeft op de databank (en bijvoorbeeld ook de users-tabel niet mag uitlezen. Alleen dmv SP's kan je dan wachtwoord verificatie doen.

[ Voor 8% gewijzigd door gorgi_19 op 26-04-2004 08:13 ]

[Verwijderd]

CaptBiele schreef op 26 april 2004 @ 04:14:
[...]

Is het echt ONMOGELIJK om aan web.config te komen? waarom zijn er dan zoveel voorstellen om nog de conn string te encrypten decrypten, zoals hier?
Is dat dan alleen om de string te beschermen tegen de beheerders die lokaal op de server kunnen oid? lijkt me niet toch?

als je dat artikel leest gebruiken ze ook base64.. das nou niet echt moeilijk om weer te decrypten dus zo veilig is dat ook weer niet. web.config is gewoon een veilige manier, anders zit je connection string in je assembly, en ook die is vrij makkelijk terug te vinden dan.

[CaptBiele]

Dus het komt er eigenlijk op neer dat web.config "gewoon" veilig genoeg is.. en dat manieren zoals het encrypten ervan niet de moeite waard zijn om te implementeren? want het neemt ook het voordeel weg dat het project niet opnieuw gecompiled hoeft te worden.

Ik denk zelf dat het ook afhangt van de gevoeligheid van de data.... ik kan me toch wel situaties bedenken dat men echt goede encryptiemethoden wil gaan gebruiken. (en dat is niet base64 nee)

[gorgi_19]

CaptBiele schreef op 26 april 2004 @ 08:30:
Ik denk zelf dat het ook afhangt van de gevoeligheid van de data.... ik kan me toch wel situaties bedenken dat men echt goede encryptiemethoden wil gaan gebruiken. (en dat is niet base64 nee)

Ik denk dat er in de meeste applicaties zorgwekkender dingen zijn dan de web.config, om eerlijk te zijn.