Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

5.2. Using the lockAttributes

Around the time that Beta 1 of ASP.NET 2.0 was worked on, the development team came up with the idea of allowing the session state feature to lock portions of its configuration. The idea was to allow developers using session state to configure application-specific behavior such as the session timeout, while allowing machine administrators to define more global settings such as the session state mode and connection string. As part of this work, the team realized that the existing 1.0/1.1 <location />-based lockdown approach was too restrictive.

For instance, if an administrator wanted to enforce just the connection string used by all applications with SQL Server session state, an administrator would also have to drag in enforced settings for session timeout, cookieless support, and so on. On some web servers, this constraint might be reasonable, but in corporate hosting environments the likelihood is rather high that different internal corporate customers want different application-specific behavior.

Rather than taking the early work for session state and limiting it to that feature, the concept of locking down individual configuration attributes as well as nested configuration elements was expanded and made available to any arbitrary configuration section. The following list describes the set of common attributes:

• lockAttributes: You can specify specific attributes on a configuration element that cannot be redefined lower down in the configuration ...