Win2003 ASP.NET - Configuration Inheritance

When the server receives a request for a specific web resource, ASP.NET uses the configuration file in the virtual directory path of the requested URL to hierarchically calculate the configuration of the resource. Settings. For example, you have a website with the following file structure, where the root of the application is the application virtual directory (Vdir).

Under normal circumstances, the last configuration setting overrides the settings for the same section provided in the parent directory, but the section handler may perform a different inheritance scheme.

For example, as an administrator, you can configure your application's settings to allow all users to access ASP.NET resources in the application root directory (that is, the physical path that maps to the application virtual directory). Only selected users can access ASP.NET resources in two subdirectories.

Assume that there is a Web.config file in the SubDir1 directory but not in the application root or SubDir2 directory. In this case, ASP.NET uses two configuration files. The highest level file is the file located in the systemroot\\Microsoft .NET \\Framework\\versionNumber\\CONFIG directory. The file is called Machine.config, which is a computer-level file, and all ASP.NET directories and subdirectories inherit their settings. Machine.config is provided with the .NET Framework and contains many default ASP.NET settings. The default configuration of the file's Security Configuration section allows all users to access all URL resources. There is no configuration file that modifies security in the sample application root, so all users have access to the ASP.NET resource (because the directory inherits the settings of the computer-level configuration file). SubDir2 inherits this setting if the Web.config file in the SubDir1 directory contains a security configuration section that only allows partial user access. Therefore, all users have access to the ASP.NET resources in the application root, but only some users can access the ASP.NET resources in SubDir1 and SubDir2.

The configuration of the virtual directory is independent of the physical directory structure. The virtual directory must be carefully organized to avoid configuration problems. For example, there might be an application called MyResource.aspx with the following physical directory structure.

C:\\Subdir1\\Subdir2\\MyResource.aspx

Assuming the configuration file is in Subdir1, the virtual directory named Vdir1 is mapped to a virtual directory mapping named cdir2 on c:\\Subdir1 Go to c:\\Subdir1\\Subdir2. If the client accesses a resource with the physical path c:\\Subdir1\\Subdir2\\MyResource.aspx using the URL http://localhost/vdir1/subdir2/MyResource.aspx, the resource inherits the configuration settings from Vdir1. However, if the client uses the URL http://localhost/vdir2/MyResource.aspx to access the same resource, the resource does not inherit settings from Vdir1. Therefore, creating a virtual directory in this way can have unintended consequences and can even make the application inoperable. We do not recommend that you do this.

Note The ASP.NET configuration system is only available for ASP.NET resources (resources registered with Aspnet_isapi.dll for processing by ASP.NET). By default, the configuration system does not provide authorization for non-ASP.NET resources. For example, all users can access ASP, HTML, TXT, GIF, and JPEG files. In the previous example, if directory browsing is enabled and there are no other restrictions, all users can view non-ASP.NET files in the application root, SubDir1, and SubDir2. For more information about ASP.NET security, see ASP.NET Security.

Configuring <location> Settings
You can apply configuration settings to specific resources by using the <location> tag with the appropriate path attribute. The path attribute can be used to indicate a specific file or subdirectory to which special configuration settings are applied.

For example, the following configuration files specify settings at three levels:

Settings applied to the current directory and all subdirectories, that is, everything contained in the top-level <configuration> tag .
The setting applied to the Sub1 subdirectory, which contains everything in the <location> tag with the path property set to Sub1.
The setting applied to the Sub2 subdirectory, which contains everything in the <location> tag with the path property set to Sub2.
<configuration>
<system.web>
<sessionState cookieless="true" timeout="10"/>
</system.web>

<!-- "Sub1" Subdirectory configuration. -->
<location path="sub1">
<system.web>
<httpHandlers>
<add verb="*" path=" ;Sub1.Scott" type="Sub1.Scott"/>
<add verb="*" path="Sub1.David" type="Sub1.David"/>
& lt; /httpHandlers & gt;
& lt; /system.web>
& lt; /location & gt;

& lt; -! " Sub2 " subdirectory configuration. -->
<location path="sub2">
<system.web>
<httpHandlers>
<add verb="*" path=" ;Sub2.Scott" type="Sub2.Scott"/>
<add verb="*" path="Sub2.David" type="Sub2.David"/>
</httpHandlers>
</system.web>
</location>
</configuration>

Lock configuration settings
By default The configuration file located in the subdirectory overrides and extends all configuration settings defined in the parent configuration file. In an application hosting scenario, administrators typically lock or prevent others from accessing certain settings on the site to prevent these settings from being modified. For example, an administrator might want to lock the sandbox security settings of a host application to prevent Web users from attacking the system.

Administrators can lock configuration settings by adding the allowOverride="false" attribute to the <location> directive. It notifies the configuration system that an error is raised if the low-level configuration file attempts to override any of the configuration sections defined in this lock <location> directive.

The following sample configuration file (which can be stored at the main system or site level) locks the trust level of two different ASP.NET applications (application1 and application2).

<configuration>
<location path="application1" allowOverride="false">
<system.web>
<trust level="High" ; /& gt;
& lt; /system.web>
& lt; /location & gt;

& lt; location path = " application2 " allowOverride = " false " & gt;
& lt; System.web>
<trust level="Medium"/>
</system.web>
</location>
</configuration>
If used The configuration settings in the example below override the configuration settings in the previous example and a configuration system error is generated.

<configuration>
<system.web>
<trust level="Full"/>
</system.web>
</Configuration>