• Choose a category
• All
• Classic-Fiction

By Root 5586 0

The attribute specifies if and how cookies are used to store the authentication ticket. It can take any of the values listed in Table 19-7.

Table 19-7. Values for the cookieless Attribute

Value

Description

AutoDetect

Uses cookies if the browser has cookie support currently enabled. It uses the cookieless mechanism otherwise.

UseCookie

Always uses cookies, regardless of the browser capabilities.

UseDeviceProfile

Uses cookies if the browser supports them, and uses the cookieless mechanism otherwise. When this option is used, no attempt is made to check whether cookie support is really enabled for the requesting device. This is the default option.

UseUri

Never uses cookies, regardless of the browser capabilities.

There’s a subtle difference between UseDeviceProfile and AutoDetect. Let’s make it clear with an example. Imagine a user making a request through Internet Explorer. The browser does have support for cookies as reported in the browser capabilities database installed with ASP.NET. However, a particular user might have disabled cookies support for her own browser. AutoDetect can correctly handle the latter scenario, and it will opt for cookieless authentication. UseDeviceProfile doesn’t probe for cookies being enabled, and it stops at what’s reported by the capabilities database. It will incorrectly opt for cookied authentication, causing an exception to be thrown.

The default value for the cookieless attribute is UseDeviceProfile. You should consider changing it to AutoDetect.

Note

When assigning a value to the cookieless attribute in the section, pay attention to how you type any of the possible values in Table 19-7. Case does matter here—for instance, UseUri is a different thing than useuri. Only the former will work.

Advanced Forms Authentication Features

Let’s tackle a few less obvious issues that might arise when working with Forms authentication.

Applications to Share Authentication Cookies

HTTP cookies support a path attribute to let you define the application path the cookie is valid within. Pages outside of that path cannot read or use the cookie. If the path is not set explicitly, it defaults to the URL of the page creating the cookie. For authentication cookies, the path defaults to the root of the application so that it is valid for all pages in the application. So far, so good.

In ASP.NET, two applications in the same Internet domain can share their own authentication cookies, implementing a sort of single sign-on model. Typically, both applications provide their own login pages, and users can log on using any of them and then freely navigate between the pages of both. For this to happen, you only have to ensure that some settings in the root web.config files are the same for both applications. In particular, the settings for the name, protection, and path attributes in the section must be identical. Moreover, a section should be added to both web.config files with explicit validation and decryption keys:

validationKey="C50B3C89CB21F4F1422FF158A5B42D0...E"

decryptionKey="8A9BE8FD67AF6979E7D20198C...D"

validation="SHA1" />

Read Knowledge Base article 312906 (located at http://support.microsoft.com/default.aspx?scid=kb;en-us;312906) for suggestions on how to create machine keys. Note that, by default, validation and decryption keys are set to AutoGenerate. The keyword indicates that a random key has been generated at setup time and stored in the Local Security Authority (LSA). LSA is a Windows service that manages all the security on the local system. If you leave the AutoGenerate value, each machine will use distinct keys and no shared cookie can be read.

Suppose now you run two ASP.NET Web sites, named www.contoso.com and blogs.contoso.com. Each of these sites generates authentication cookies not usable by the other. This is because, by default, authentication cookies are associated with the originating domain. All HTTP cookies, though, support a domain attribute, which takes the flexibility of their path attribute