• Choose a category
• All
• Classic-Fiction

The Section

The section is used to define a declarative filter to control access to the resources of the application. The section contains two subsections, named and , that can be used to allow and deny access to users. Both elements feature three attributes—users, roles, and verbs—filled with a comma-separated list of names, as the following code demonstrates:

roles="comma-separated list of roles"

verbs="comma-separated list of verbs" />

roles="comma-separated list of roles"

verbs="comma-separated list of verbs" />

The element authorizes access to any user whose name appears in the list—that is, to all users with any of the specified roles. Authorized users can execute only the HTTP verbs (for example, POST and GET) indicated by the verbs attribute.

Conversely, the element prohibits listed users from executing the specified actions. The default setting allows all users free access to the resources of the application. When specifying the user name, a couple of shortcuts are allowed. The asterisk (*) means “all users,” whereas the question mark (?) stands for the “anonymous user.”

Important

The section is all about declarative authorization. It uses a fixed syntax to feed authorization modules (UrlAuthorization and FileAuthorizationModule) and have them block unauthorized users as they try to access a URL or a file. Most applications, instead, prefer to incorporate authorization within their business layer in a fluent way. In doing so, applications associate users with roles and check roles before proceeding with any critical operations. For this approach, you don’t need the section. The section, however, remains quite useful for relatively simple scenarios when you just want to limit access to a specific subset of users or protect the entire content of pages in a given area of the application. (See Chapter 19.)

The Section

The section enumerates the characteristics and capabilities of the supported browsers, including mobile devices. The section is tightly coupled with the HttpBrowserCapabilities class and MobileCapabilities, which allows the ASP.NET runtime to gather technical information about the browser that is running on the client.

So ASP.NET supports the concept of browser capabilities and gives you a chance to check them and build your applications accordingly. You use any browser information available through the Browser property of the intrinsic Request object. The point is, where would ASP.NET find information to feed the Browser property?

Internally, the Request object first looks at the user-agent information that comes with the HTTP request and then matches this information to some sort of provider. The internal structure of the browser provider has evolved quite significantly lately and especially in ASP.NET 4.

In the beginning, the section was the only repository for browser information. Under the section, you find a number of commercial browsers described in terms of their run-time capabilities, such as cookies, tables and frames support, accepted script languages, XML DOM, and operating system. The element can be declared at any level in the application, thus making it possible for you to enable certain levels of browser support for certain applications. The list of available browsers can be updated as required to detect future browsers and browser capabilities. The use of the element to define browsers was deprecated already in ASP.NET 2.0. It is, however, fully supported still today.

An alternate approach to using is reading browser information from matching files with a .browser extension located in the folder Microsoft.NET\framework\[version]\config\browsers. Figure 3-2 shows the default content of