Form validation cookieless properties under ASP.net 2.0

asp.net|cookie| Form Validation

Just in the laundry when suddenly think of today in the WAP program to do the form verification encountered a problem, in the mobile device simulator does not support cookies can not be the normal form validation, Lenovo to use Web.config yesterday to set the cookieless property when the access will appear " Cannot use a leading. To exit above ' top directory ' exception, naturally I thought of a time ago that bothered me for a while. A site exception cannot use a leading ... Exits at the top-level directory (cannot use a leading. To exit above the top directory). Together, finally understand why there is such an exception, but also understand why in ASP.net 2.0, the original cookieless property can only set the True|false, changed to set the enumeration HttpCookieMode values, respectively: Autodetect,usecookies,usedeviceprofile,useuri.

A friend who is experienced with form validation may be aware that there are two ways to save current SessionID and user authentication ticket information, using cookies and a string of encoded strings at the URL address to identify the current SessionID and user's validation ticket information. The first way is very common, for using URIs to identify current SessionID and verification tickets, I believe that if it is not a special need, I believe that many people will not be able to understand as well as I do. I made two simple pages to simulate the user verification process. When I set cookieless= "AutoDetect" in web.config, as we normally do, the login URL is:

Http://localhost:1115/FormsAuthentication/Security/Default.aspx

And when I set cookieless= "UseUri", the URL address becomes:

http://localhost:1115/FormsAuthentication/(F ( V0-GEZNEZXUQEVBOQKWNOBCMF6VBWNYNBDPA2UHZZRFOUKGPVYB91-9NFLNBDMCAGDPZ4GJ6KQ-QOVJBNSVKIG2))/Security/ Default.aspx

In the site directory more than a level of directory, where the value is the current user's verification ticket information and SessionID information. In some cases, this is very meaningful (or necessary), because in the context of not supporting cookies, you have to identify whether it belongs to the same session, whether the current user has been validated, and so on, and so on session related information will become unusually difficult.

Having learned the two ways to save session information, let's discuss why the ASP.net team can only set the original to TRUE | False to set different enumeration values. First, let's take a look at the implications of these 4 values (in Windows Live Writer cannot draw table:<):

AutoDetect: Automatically detects whether the client actually supports cookies and then decides which of the two methods (best fit) to use.

UseCookies: Use cookies to identify (the first way), regardless of whether the client supports cookies.

UseDeviceProfile: Depending on the device file to determine whether to support cookies, and then decide which way to use. I believe a lot of people are very vague about this concept, because recently in the study of WAP, so there are some simple understanding of it. In <%windir%>microsoft.net\framework\v2.0.50727\config\ There are a lot of. browser files in the browsers directory that identify the browsing capabilities of the corresponding device (browser) (descriptions are not very clear, some technical parameters, and whether cookies and so are supported). In asp.net, according to these. browser files, dynamically generate the device parameter types inherited from HttpBrowserCapabilities, identify some parameter values of the corresponding device, and programmatically get the device parameter object by Request.Browser, and use it.

UseUri: Similar to usecookies, regardless of whether the client supports cookies, the second way is used anyway.

Special Note: Why special emphasis on "practical", and detailed description of UseDeviceProfile? Mainly because I found that the parameters identified in the device file might not exactly match the actual device, (for example, it is possible to identify the device in the device file to support cookies, but the actual device does not). So if you choose whether to use cookies based on the actual device, use the AutoDetect value. Device files can only be used as a reference, of course, if you have sufficient control of the equipment file is another matter. And there is one thing to pay special attention to, AutoDetect is not the default value, UseDeviceProfile is.

Back to the point, why do you want to change the cookieless attribute optional value? There is no doubt in order to increase the maneuverability of the program. The original value is a bit too single, two choose one, there is no room for negotiation. Now we can make the program dynamic or the programmer choose manually according to various situations. Combined with this period of WAP development experience, I think one of the purposes of this is to better compatible with mobile devices, compatible with WAP applications. There are still many devices that do not support cookies at this time.

With the above introduction, I also want to solve why there is "cannot use a leading." To exit above is the "top directory" unusual puzzle. A few days ago also received a letter from a friend, but also in the use of CommunityServer 2.0 encounter this problem, (I believe that the most is currently encountered is the ASP.net 2.0 version of the CommunityServer). Currently using the URL Rewrite, so many of our programs are fake URLs, so if the use of relative path in the page (~/), then we may encounter such trouble. Because the search engine (especially Google) does not support cookies, so when it visited the site will use the second mentioned above to identify the session information, this time the URI is more level, so in this page all the link address is one more. /, unable to access the normal, resulting in the occurrence of the above exception. (In fact, it can be seen that the exception itself and the URL rewrite not much of a relationship, but not communityserver and my program are using the URL rewrite).

There are three ways to solve the problem:

1. Set cookieless = usecookies, use cookies regardless of whether the client supports cookies.

2. Because the default cookieless = UseDeviceProfile, you can create a device file for the search engine. Browser, fake it. This has been done with the GoogleBot to crash your. NET 2.0 site.

3. Modify the program to change the relative path inside (~/) to an absolute path representation (you can use the Resolve method).

So far as the discussion of cookieless has come to an end, I find that the Chinese community has so far not seemed to have had a lot of people discussing this attribute. Many of the text is my personal comprehensive understanding, summed up, there may be a lot of wrong understanding and views, welcome to me to correct and add.