Some Membership Authentication methods rely on the use of cookies deposited on the user's computer. A cookie is a general mechanism that the IIS Web server software uses to both store and retrieve information on the end user’s side of the connection. The Web server deposits on the end user’s computer a state object called a cookie which includes the current state plus the URLs for which this state is valid. Any future HTTP requests made by the end user’s computer include the current value of the cookie.
Some browsers and auxiliary software allow users to automatically reject cookies. In such cases, if you must use a type of authentication that requires cookies, determine the default behavior when the user rejects cookies. Then if it does not suit your needs, you can modify it.
The Membership Authentication methods that require cookies, and the behavior that occurs if the user does not accept the cookie, are listed in the following table.
| Authentication Method | Behavior if cookies are not accepted |
|---|---|
| HTML Forms Authentication |
User is denied access and is returned to the formslogin page. From there he or she can repeat the login attempt or link to a registration page. (C:\Microsoft Site Server\Sites\samples\knowledge\membership\sampapps\security\formslogin.asp) The system attempts to find a formslogin.asp file by beginning in the directory where the user was denied access and walking up the URL to the root. |
| Automatic Cookie Authentication | User cannot be authenticated and is redirected to an error page (C:\Microsoft Site Server\Sites\samples\knowledge\membership\sampapps\security\\nocookie.asp). |
| Distributed Password Authentication (DPA) | Problems only if used across a proxy. User is denied access and is redirected to the Troubleshooting pages (C:\Microsoft Site Server\Sites\samples\knowledge\membership\sampapps\security\\troubleshooting\default.asp). DPA, when not used across proxies, uses cookies but reverts to an alternate method if the user does not accept cookies. The inability to connect across proxies was solved using cookies, and if used across proxies, DPA fails if cookies are not accepted. |
If a site is using DPA across proxies, modify the troubleshooting pages to notify the users that they must accept cookies in order to access the site.
If a site is using Automatic Cookie Authentication, the error page already alerts the user to the problem.
In such cases, or if the default methods are not acceptable for any reason, there is an alternative. You can create a set of Web pages under a different virtual directory that do not contain any personalization and are not protected by any authentication method that requires cookies. Then have the error return redirect the user to this non-personalized content rather than to the error page.
Often this involves duplicating some of the functionality of the site:
By using this method, personalization scripts can be authored with the assurance that any users who visit that site have been identified. Users who choose not to accept cookies can see any content that you decide they should see.
System behavior is also affected when cookies are rejected, regardless of the authentication method used. If user properties are changed from an ASP script, the AUO invalidates the Authentication Service cache on that Web server computer and issues a Recent Change cookie. The cookie, if accepted, notifies the Authentication Service that if there are a number of replicated Membership Directories, this user’s properties should be retrieved from the master Membership Directory because others may not have been updated.
If the user is rejecting cookies, and the site has multiple Web server computers, it is possible that the user may be connected to a different Authentication Service whose cache has not been invalidated, and in the absence of the cookie the changes to the user’s properties may not appear.
A different problem involves the AUO configuration. The AUO may be configured to use either the remote_user variable or a cookie as a suffix. For Membership Authentication, remote_user (the user name) is the default, while for Windows NT Authentication the cookie is the default (see Configuring AUO).
If the AUO is configured to use the cookie suffix and the user rejects cookies, the AUO cannot initialize, and this causes a script error, stopping the process of Web page delivery. If script writers use the On Error Resume Next command, the script will execute, but no personalization can take place. The only workaround for Windows NT Authentication is to require an authentication method that does not use cookies (NTLM or Clear Text/Basic), or to modify the AUO to use the remote_user suffix instead of the cookie suffix.