• Choose a category
• All
• Classic-Fiction

Another small number of threads (four by default) is kept reserved for child requests coming through the local host. If the request has been generated locally—that is, the client IP is 127.0.0.1 or matches the server IP—it is scheduled on one of the threads in the pool reserved for local calls. Often local requests originate as child requests—for example, when an ASP.NET page invokes a Web service on the same server. There’s no need in this case to consume two threads from the pool to serve two related requests, one of which is waiting for the other to terminate. By using an additional thread pool, you actually assign local requests a slightly higher priority and reduce the risk of deadlocks.

The Section

The section controls the identity of the ASP.NET application. It supports three attributes: impersonate, userName, and password. The key attribute is impersonate. It is set to false by default, which means that the application does not impersonate any client user.

When impersonate is set to true, each request is served by ASP.NET impersonating either the Windows user currently logged on or the user specified through the userName and password attributes.

Note that user name and password are stored in clear text in the configuration file. Although IIS never serves requests for configuration files, a web.config file can be read by other means. You should consider forms of protection for the contents of the section. In ASP.NET, you can encrypt the section using XML Encryption.

The Section

Valid at the machine and application levels, the section configures the keys to encrypt and decrypt forms authentication tickets and view-state data. Here’s the schema:

validationKey="AutoGenerate,IsolateApps"

decryptionKey="AutoGenerate,IsolateApps"

validation="HMACSHA256"

decryption="Auto" />

The validationKey and decryptionKey attributes are strings and specify the encryption and decryption keys, respectively. An encryption key is a sequence of characters whose length ranges from a minimum of 40 characters to a maximum of 128.

The validation attribute, on the other hand, indicates the type of encryption used to validate data. Allowable values are SHA1, MD5, 3DES, AES, HMACSHA256 (the default), HMACSHA384, and HMACSHA512.

Finally, the decryption attribute indicates the type of hashing algorithm that is used for decrypting data. Feasible values are DES, AES, and 3DES. The default is Auto, meaning that ASP.NET determines which decryption algorithm to use based on the configuration default settings.

The default value of both the validationKey and decryptionKey attributes is AutoGenerate,IsolateApps. This means that keys are autogenerated at setup time and stored in the Local Security Authority (LSA). LSA is a protected subsystem of Windows NT–based operating systems that maintains information about all aspects of local security on a system. The IsolateApps modifier instructs ASP.NET to generate a key that is unique for each application.

Settings in the section are a critical element of applications hosted on multiple machines, such as in a Web farm or a failover cluster. All machines across a network must share the same settings. For this reason, you might want to set validationKey and decryptionKey attributes manually to ensure consistent configuration in a multiserver environment.

The Section

The section defines parameters for managing and authenticating user accounts through the ASP.NET membership API. Here’s the schema of the section:

defaultProvider="provider name"

userIsOnlineTimeWindow="number of minutes"

hashAlgorithmType="SHA1">

...

The defaultProvider attribute indicates the name of the default membership provider—it is SqlMembershipProvider by default. The attribute