Structure of Configuration Files

for RuBoard

As mentioned earlier, ASP.NET configuration files are XML documents. The root node of the document is always called configuration. Within the configuration node are a variety of nodes and subnodes that contain additional settings; these are grouped into section handlers.

The next few sections describe the default section handlers in the System.Web section of a Web configuration file. Because each Web.Config file ultimately inherits its settings from Machine.Config, the descriptions apply to both files.

Authentication Settings

Authentication refers to the process whereby a user is granted or denied access to the page based on security credentials.

ASP.NET supports three authentication modes:

  • Windows authentication

  • Cookie-based authentication

  • Microsoft Passport authentication

In Windows authentication, the user has an account on the Windows NT/Windows 2000 server on which the Web application is located; if the user is not located on the same subnet as an authenticating server, the user must supply a username and password when the browser initially accesses a Web application.

In cookie-based authentication, an encrypted chunk of data is deposited on the user's computer and read by the server each time the user accesses the site.

Passport authentication is similar to cookie-based authentication. It enables users to use the same security credentials to access any one of a number of sites. This is accomplished by storing and authenticating user information in a central location (managed by Microsoft).

NOTE

It is possible to use Passport authentication whether or not your site uses ASP.NET. You can get more information about implementing Passport authentication on your site at http://www.passport.com/business.


To specify one of these authentication schemes, you make a change to the authentication section of the Web.Config or Machine.Config files.

Figure 5.1 shows a typical authentication section and describes some of its settings.

Figure 5.1. Description of the authentication section of the Web configuration file.

graphics/05fig01.gif

The details of implementing various authentication methods are discussed in Chapter 7, "Security."

Authorization Settings

An authorization is a permission that belongs to a user. This is different from authentication. Authentication determines who the user is, whereas authorization determines what that user is allowed to do.

Authorization settings are based on the user's identity as determined by the operating system. This identity is typically established through the user logging in to a Windows NT/2000 domain. In ASP.old, users who access your Web application anonymously (as is often the case with public Internet applications) have a login identity; the username is IUSR_MACHINE where MACHINE is the name of the server. In ASP.NET, code is executed under a restricted account called ASPNET; ASP.NET will not impersonate an authenticated user (including the default IUSR_MACHINE) unless specifically configured to do so.

To specify one of these authorization modes, you create entries in the authorization section of the Web.Config or Machine.Config files. To permit a user or group to access the application, you create an entry in the allow subsection of the authorization section. To explicitly deny users or groups access to the application, create an entry in the deny subsection.

You can denote "all users" in an allow or deny section by using an asterisk ( * ). To denote anonymous users, use a question mark ( ? ). You can denote multiple users by creating a comma-delimited list of users and/or groups. In this case, groups are collections of users as defined in Windows NT/2000 security settings on the server.

Browser Capabilities Settings

Browser capabilities refer to the way that ASP.NET detects whether clients ' Web browsers have the capability to process special features such as cookies, JavaScript, and so on. Certain features of ASP.NET have the capability to tailor themselves to different browser types. An example of this is a validation control, which can emit client-side JavaScript for browsers that support it or fall back to server-side validation for non-JavaScript browsers. (For more on how this works, see Chapter 9, "Building User Controls and Server Controls.")

To add browser capabilities information, you insert a section in the browserCaps section of the Web.Config or Machine.Config files.

Compilation Settings

Compilation settings cover a range of attributes that pertain to how the ASP.NET application uses the compiler. These settings are crucial because of the way that ASP.NET provides seamless integration with the .NET compilers. The compilation section also contains debugging settings.

To change a compilation setting, you make a change to the compilation section of the Web.Config or Machine.Config files.

Figure 5.2 shows a typical compilation settings section and describes some of its settings.

Figure 5.2. Description of the compilation settings section of the Web configuration file.

graphics/05fig02.gif

Explicit and Strict attributes in compilation section are applicable only to VB .NET. However, C# compiler ignores these settings.

Custom Error Settings

You can change the way that ASP.NET deals with errors by adjusting settings in the customErrors section of the Web.Config or Machine.Config files. By making changes in this section, you can specify a page to redirect to when various errors occur.

Figure 5.3 shows a typical customErrors section and describes some of its settings.

Figure 5.3. Description of the customErrors section of the Web configuration file.

graphics/05fig03.gif

The error subsection of the customErrors section can appear multiple times in a single Web configuration document; each section can have a different HTTP result code mapping, thereby causing the browser to redirect to a different page when an error occurs.

Execution Timeout Settings

The execution timeout section provides a serverwide or applicationwide setting that controls how long a script is permitted to run before it times out. This can be overridden by using a page-level directive.

To change the execution timeout, you make a change to the value attribute of the executionTimeout section of the Web.Config or Machine.Config files. This integer value represents the number of seconds that scripts are permitted to run before ASP.NET will generate an error.

Globalization Settings

The globalization section determines the international language settings for a Web application. This information includes the encoding types both for requests and responses. It also controls culture-specific settings.

To specify a globalization setting, you make a change to the globalization section of the Web.Config or Machine.Config files.

Figure 5.4 shows a typical globalization section and describes some of its settings.

Figure 5.4. Description of the globalization section of the Web configuration file.

graphics/05fig04.gif

HTTP Handler Settings

An HTTP handler is a component that intercepts and handles HTTP requests at a lower level than ASP.NET is capable of handling.

To add an HTTP handler to your server, you make a change to the httpHandlers section of the Machine.Config file.

The order of entries in the httpHandlers section is significant. Handlers that are entered lower in the list take precedence over like-named entries that appear higher in the list.

See Chapter 8, "HttpHandlers and HttpModules," for more information on custom HTTP handlers in ASP.NET.

HTTP Module Settings

To add an HTTP module to your system, you make a change to the httpModules section of the Web.Config or Machine.Config files.

The order of entries in the httpModules section is significant. Modules that are entered lower in the list take precedence over like-named entries that appear higher in the list.

Page Settings

<pages> settings control how individual ASP.NET pages are rendered in the browser. This section controls such settings as enableSessionState, enableViewState, buffer, and autoEventWireup.

To change page settings, you make a change to the pages section of the Web.Config or Machine.Config files.

Figure 5.5 shows a typical pages section and describes some of its settings.

Figure 5.5. Description of the <pages> section of the Web configuration file.

graphics/05fig05.gif

Page settings such as buffer, autoEventWireup, and enableViewState are covered in Chapter 2, "Page Framework."

Process Model Settings

Process model settings control how your Web application uses certain system resources, such as CPUs on a multiple-processor machine. It also gives you control over how IIS assigns processes to ASP.NET requests. You can change these settings to tune performance.

To change processModel settings, you make a change to the processModel section of the Web.Config or Machine.Config files.

Figure 5.6 shows a typical processModel section and describes some of its settings.

Figure 5.6. Description of the processModel section of the Web configuration file.

graphics/05fig06.gif

Session State Settings

Session state settings determine how user session information is stored by ASP.NET. In ASP.NET you can store user session information either in process (in memory on the same machine as the Web server), out of process (even on a separate machine), or in Microsoft SQL Server.

To change Session state settings, you make a change to the sessionState section of the Web.Config or Machine.Config files.

Figure 5.7 shows a typical sessionState section and describes some of its settings.

Figure 5.7. Description of the sessionState section of the Web configuration file.

graphics/05fig07.gif

The various session state options available in ASP.NET are discussed in more detail in Chapter 2.

Trace Settings

Trace settings are typically used for debugging purposes. You activate Trace mode in ASP.NET when you want to show the output of trace code (calls to the Trace method of the System.Web.TraceContext object).

To turn tracing on, you set the enabled attribute to true in the trace section of the Web.Config or Machine.Config file.

Figure 5.8 shows a typical trace section and describes some of the trace section's other settings.

Figure 5.8. Description of the trace section of the Web configuration file.

graphics/05fig08.gif

Tracing an ASP.NET application is discussed in more detail in Chapter 3, "Debugging ASP.NET Applications."

Web Services Settings

XML Web services settings enable you to control settings pertaining to the exposure of Web services functionality on the Web server. Remember that in .NET, XML Web services is a superset that comprises a number of Web protocols, including SOAP, HTTP POST, and HTTP GET. All XML Web services protocols are configured in the same section of the Web configuration file.

To specify an XML Web services setting, you make a change to the webServices section of the Web.Config or Machine.Config files.

XML Web services are discussed in more detail in Chapter 6, "Web Services."

Configuring Multiple Locations in Web.Config

The Web.Config file supplies settings for scripts found in that directory. If no Web.Config file exists in a given directory, configuration settings are inherited from the parent directory; if no Web.Config file exists there, the settings from Machine.Config are used.

This situation can lead to problems in managing the configuration of a complex Web application with many subdirectories. If you have three levels of subdirectories, each with its own set of permissions, you could easily have a half- dozen Web.Config files in various locations in your application directory hierarchy.

You can get around this problem by placing a location section in Web.Config. A location section enables you to manage special permissions for subdirectories in one Web.Config file, located in a parent directory.

For example, suppose your Web application contains a root directory and two subdirectories, as illustrated in Figure 5.9.

Figure 5.9. Hierarchical Web application directories example.

graphics/05fig09.gif

To specify different settings for scripts contained in the three directories that compose this application, you could include three separate Web.Config files, one in each subdirectory; or you could create a single Web.Config file in the \myapp directory and include location sections that apply to the subdirectories \img and \inc.

Listing 5.1 shows an example of a Web.Config file that has separate settings for files located in subdirectories.

Listing 5.1 Web.Config File Example with Location Section to Handle Subdirectory Settings
 <configuration>    <!-- Configuration for the current directory -->    <system.web>       <compilation debug="false"/>    </system.web>  <!-- Configuration for \img -->    <location path="img">       <system.web>         <compilation debug="false"/>       </system.web>    </location>    <!-- Configuration for \inc -->    <location path="inc">       <system.web>         <compilation debug="true"/>       </system.web>    </location> </configuration> 

You can see that this file contains two sections that correspond to the two subdirectories (\img and \inc) underneath the application directory. Each location section in the configuration file contains settings that are normally found under the system.web section.

You can test this by putting ASP.NET scripts that contain syntax errors into each of the three directories and then navigating to them in the browser. You should be able to see that scripts in the \inc directory will provide debugging information when they fail, whereas scripts in the \img and \myapp directories will not.

Locking Down Web Configuration Settings

Although Web configuration files can inherit their settings from other configuration files, you may want to prevent subordinate configuration files from changing certain settings.

For example, for security reasons you may want to turn off debugging at the level of Machine.Config, thereby preventing any ASP.NET application on that server from going into debug mode when an error occurs. Shutting down debugging is important because turning on the debug attribute can expose your source code to the user.

To lock down a configuration setting, you use the allowOverride attribute, found in the <location> element. This attribute is a Boolean; when set to false , Web configuration files that inherit from the current file cannot change the settings in the section.

for RuBoard


C# Developer[ap]s Guide to ASP. NET, XML, and ADO. NET
C# Developer[ap]s Guide to ASP. NET, XML, and ADO. NET
ISBN: 672321556
EAN: N/A
Year: 2005
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net