In an asp.net app the web.config has an ideal place to store app settings like email-response adresses or database connection-strings. In the appsettings section you can stash any string you want.
<appSettings>
<add key="dbConnectionString" value="workstation id=FARLOWELLA;user id=ThatsMe;data source=phelsuma;persist security info=False;initial catalog=Indato;pwd=MyOhSoSecretPassword"></add>
<add key="StyleSheet" value="StyleSheetIndato.css"></add>
<!-- Directory to create and delete temporary files. ASP.NET requires fieldcreate and filedelete rights ! -->
<add key="TempDir" value="c:\temp\"></add>
</appSettings>
Clear language for a system administrator. When IIS loads the application the web.config file is parsed. Now all settings are available in your code.
public static void openConnection(SqlConnection cn, string settingName)
{
cn.ConnectionString = System.Configuration.ConfigurationSettings.AppSettings[”dbConnectionString”];
That’s cool. If the system administrator wants to change the database used he edits the web.config. But if the application is still running, the web.config has allready been parsed. When the timestamp of the web.config is updated IIS will restart your application. (In the code the application_start event of global.asx fires)
Doing application maintenace by editing a configuration file is easy but exposing the settings as plain text in that file has a security risk. To view web.config you need network or local access to the server. IIS labels a “*.config” application mapping as forbidden. By default no web client can view it. But this setting can be changed in the IIS administrator. As a last hurdle you can encrypt the contents of web-config. Check here for an OnDotNet story on encrypting connectionstrings in 2.0.
The dbconnectionstrings are an almost classical example of what to do with web.config. It is a pitty the content of most of the dbconnectionstrings is far less secure than possible. Allmost all contain a user name, password combination. An application is running under the asp.net account. This is a pretty restricted account, the many priviliges the connectionstring-user has are far to powerfull for the job. They migth even prove dangerous when the user (unintentionally) does something bad. Consider the effects of a sql injection attack. The application does not need the right to drop databases.
Instead of using user based security you can use integerated security (Old dnj story on this). Then you assign the db rights straight to the asp.net account itself. This will result in a connectionstring like
data source=BROCHIS;initial catalog=DNJ;integrated security=SSPI;
This is far less informative to evil eyes than the one with the password of the system adminstrator.