We store application settings or other entries which need to be configured from time to time in configuration files. It...
A central requirement of any Web application server is a rich and flexible configuration system-—one that enables developers to easily associate settings with an installable application (without having to “bake” values into code) and enables administrators to easily customize these values post-deployment, The ASPNET configuration system has been designed to meet the needs of both of these audiences; it provides a hierarchical configuration infrastructure that enables extensible configuration data to be defined and used throughout an application, site, and/or machine. It has the following qualities that make it uniquely suited to building and maintaining Web applications:
ASP.NET allows configuration settings to be stored together with static content, dynamic pages, and business objects within a single application directory hierarchy. A user or administrator simply needs to copy a single directory tree to set up an ASP.NET application on a machine.
Configuration data is stored in plain text files that are both human-readable and human-writable. Administrators and developers can use any standard text editor, XML parser, or scripting language to interpret and update configuration settings.
ASPNET provides an extensible configuration infrastructure that enables third-party developers to store their own configuration settings, define the persistence format of their own configuration settings, intelligently participate in their processing, and control the resulting object model through which those settings are ultimately exposed.
Changes to ASPNET configuration files are automatically detected by the system and are applied without requiring any user intervention (in other words, an administrator does not need to restart the Web server or reboot the machine for them to take effect).
Configuration sections can be locked down when using the <location> tag and the allowOverride attribute.
Configuration File Format
ASP.NET configuration files are XML—based text files—each named web.config –that can appear in any directory on an ASPNET Web application server. Each web.config file applies configuration settings to the directory it is located in and to all virtual child directories beneath it. Settings in child directories can optionally override or ` modify settings specified in parent directories. The root configuration file– Windows\Microsoft.NET\Framework\<version>\config\machine.config — provides default configuration settings for the entire machine. ASP.NET configures IIS to prevent direct browser access to web.config files to ensure that their values cannot become public (attempts to access them will cause ASP.NET to return 403: Access Forbidden).
At run time ASP.NET uses these web.config configuration files to hierarchically compute a unique collection of settings for each incoming URL target request (these settings are calculated only once and then cached across subsequent requests; ASP.NET automatically watches for file changes and will invalidate the cache if any of the configuration files change).
For example, the configuration settings for the URL http://myserver/myapplication/mydir/page.aspx would be computed by applying web.config file settings in the following order.
Base configuration settings for machine.
Overridden by the configuration settings for the site (or the root application).
Overridden by application configuration settings.
Overridden by subdirectory configuration settings.
If a web.config file is present at the root directory for a site, for example “Inetpub\wwwroot”, its configuration settings will apply to every application in that site. Note that the presence of a web.config file within a given directory or application root is completely optional. If a web.config file is not present, all configuration settings for the directory are automatically inherited from the parent directory.
Configuration Section Handlers and Sections
A web.config file is an XML-based text file that can contain standard XML document elements, including well-formed tags, comments, text, data and so on. The file may be ANSI, UTF-8, or Unicode; the system automatically detects the encoding. The root element of a web.config file is always a <configuration> tag. ASP.NET and end-user settings are then encapsulated within the tag, as follows:
<configuration> <!- Configuration settings would go here. --> </configuration>
The tag typically contains three different types of elements: 1) configuration section handler declarations, 2) configuration section groups, and 3) configuration section settings.
Configuration section handlers – The ASP.NET configuration infrastructure makes no assumptions regarding the tile format or supported settings within a web.config file. Instead, it delegates the processing of web.config data to configuration section handlers, NET Framework classes that implement the IConfigurationSectionHandler interface. An individual IConfigurationSectionHandler declaration needs to appear only once, typically in the machine.config file. The web.config files in child directories automatically inherit this declaration. Configuration section handlers are declared within a web.config file using section tag directives nested within a <configSections> tag. Section tags may be further qualified by section group tags to organize them into logical groups (see below). Each section tag identities a tag name denoting a specific section of configuration data and an associated IConfigurationSectionHandler class that processes it.
Configuration section groups – ASP.NET configuration allows hierarchical grouping of sections for organizational purposes. <sectionGroup> tag may appear inside a <configSections> tag or inside other tags. For example, ASP.NET section handlers all appear within the section group.
Configuration sections – ASP.NET configuration settings are represented within configuration tag sections, also nested within a <configuration> tag (and optional section group tags). For each configuration section, an appropriate section handler must be defined in the config hierarchy. For example, in the sample below, the tag <httpModules> is the configuration section that defines the HTTP modules configuration data. The System.Configuration.HttpModulesConfigurationHandIer class is responsible for interpreting the content contained within the tag at run time. Note that both the section handler definition and the section must have the same section group qualifier (in this case, ). Also note that tag names are case-sensitive and must be typed exactly as shown. Various attributes and settings for ASP.NET are also case-sensitive and will not be examined by the configuration runtime if the case does not match.
<configuration> <configSections> <sectionGroup name="system.web"> <section name="htttpModules" type="System.Web.Configuration.HttpModulesConfigu:ati0nHandle:,System.Web" /> </sectionGroup> </configSections> <system.web> <httpModules> <add name="CookielessSession" type="System.Web.SessionState.CookielessSessi0nM0dule,System.Web" /> <add name="OutputCache" type="System.Web.Caching.OutputCacheModule,System.Web"/> <add name="Session" type="System.Web.Sessionstate.SessionStateModule,System.Web" /> <add name="WindowsAuthentication " type="System.Web.Security.WindowsAuthenticationModule,System.Web" /> <add name=" FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule, System.Web" /> <add name="PassportAuthentication" type="System.Web.Security.PassportAuthenticationModule,System.Web" /> <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule , System. Web"/> <add name="FileAuthorization" type="System.Web.Security.FileAuthoxizationModule,System.Web"/> < /httpModules> </system.web> </configuration>
Locking down configuration settings
In addition to specifying path information using the <location> tag, you can also specify security so that settings cannot be overridden by another configuration file further down the configuration hierarchy. To lock down a group of settings, you can specify an allowOverride attribute on the surrounding <location> tag and set it to false. The following code locks down impersonation settings for two different applications.
<configuration> <location path="app” allowOverride="false"> <system.web> <identity impersonate="false" userName="app1' password=”app1pw" /> </system.web> </location> <location path="app2" allowOverride="false"> <system.web> <Identity Impersonate="false "userName=" app2" password=”app2pw” /> </system.web> </location> </configuration>
Note that if a user tries to override these settings in another configuration file, the configuration system will throw an error.
<configuration> <system.web> <identity userName="developer" password="loginpw” /> </system.web> </configuration>
Standard ASP.NET Configuration Section
ASP.NET ships with a number of standard configuration section handlers that are used to process configuration settings within web.config files. The following table provides brief descriptions of the sections, along with pointers to more information.
<httpModules>: Responsible for configuring HTTP modules within an application. HTTP modules participate in the processing of every request into an application. Common uses include security and logging.
<httpHandlers>:Responsible for mapping incoming URLs to IHttpHandler classes. Subdirectories do not inherit these settings. Also responsible for mapping incoming URLs to IHttpHandlerFactory classes. Data represented in <httpHandlers> sections are hierarchically inherited by subdirectories.For more information, see the Http Handlers and Factories section of this tutorial.
<sessionState>: Responsible for configuring the session state HTTP module. For more information, see the Managing Application State section of this tutorial.
<globalization>: Responsible for configuring the globalization settings of an application. For more information, see the Localization section of this tutorial.
<Compilation>: Responsible for all compilation settings used by ASPNET. For more information, see the Business Objects and Debugging sections of this tutorial.
<trace>: Responsible for configuring the ASP.NET trace service. For more, information, see the Tracing section of this tutorial.
<processModel>: Responsible for configuring the ASP.NET process model settings on IIS Web server systems.
<browserCaps> : Responsible for controlling the settings of the browser capabilities component. For more information, see the Retrieving Configuration section of this tutorial.