A problem encountered by Asp. Net Forms authentication on mobile platforms and the investigation process

The mobile version of our project website is based on Asp.. Net platform, user logon is also based on Asp.. Net Forms authentication. No client logon exception is found throughout the development and testing process. However, after the release, users are reported to jump to the home page after the logon is successful, the homepage does not recognize logon users, that is, Form authentication fails. You should understand Asp. Net Form authentication. The internal mechanism is to encrypt user data and save it in a cookie-based ticket FormsAuthenticationTicket, that is, cookie is used in the authentication process. Initially, the problem lies in cookie. The following is the investigation process.

Build a debugging environment

In mobile platform web development, debugging is not as easy as in desktop web development. The difficulty lies in the diversity of mobile devices, and there are few tools for debugging on mobile devices. To test the problem above, we use a powerful HTTP monitoring tool Fiddler. Fiddler allows remote devices to access the server through proxy, so that Fiddler can monitor HTTP requests from mobile devices. The settings in Fddler are as follows:

 

 

Set the network access proxy of the mobile device to the IP address of the host where Fiddler is located, and set the monitoring port number for Fiddler, as shown in, so that all HTTP requests of mobile devices can be monitored.

Confirm the problem

After the test environment is set up, confirm the problem and the user cannot log on. Is the cookie lost? The authenticated cookie is set on the login screen. The login screen requests are sent over HTTPS, while the home page requests are sent over HTTP. After the user logs on, the authentication cookie is successfully set on the login page, and the authentication cookie is sent back to the server when the homepage request is sent. The monitoring information is shown as follows:

Cookie set on the logon screen

 

 

Cookie sent back to the server on the homepage

 

 

At this point, we can determine that the problem is not on the client but on the server. Why cannot the server identify the returned authentication information? Why do some devices fail to log on? The only difference between the browser requests sent from these devices to the server is the user-agent. What does the server do for the user-agent? With these problems, I have thoroughly studied ASP. NET authentication principles and some cookies in ASP. NET.
Deep understanding of cookieless's Application in ASP. NET Form Authentication
To confirm why the server has not been successfully authenticated, you must understand the cookieless function in ASP. Net.
There are many reasons for cookie invalidation. Some users disable cookies and some devices do not support cookies. Therefore, ASP. NET has a cookieless feature, so that when the cookie fails, it can also provide a function similar to the cookie. For example, you can pass the information through the URL, cookieless is added for this purpose.
Cookieless has four modes in total:
1. "UseCookies", that is, the cookieless function does not enable www.2cto.com
2, "UseUri", that is, cookieless is enabled for all devices.
3. "UseDeviceProfile": determines the application or does not apply Cookieless Based on the browser that initiates the request. If ASP. NET recognizes that the browser does not support cookies, cookieless is enabled. In addition, technically, if the Browser supports Cookies, the values of the following two attributes are true: Request. Browser. Cookies and Request. Browser. SupportsRedirectWithCookie.
4. "AutoDetect", which can be understood directly by ASP. NET to check whether the current browser supports cookies. This mode is somewhat confusing and complicated. The official documentation provides pseudocode that explains this mode.
In the preceding modes, UseDebiceProfile and AutoDetect modes depend on devices and ASP. NET maintains a database, which is generally stored in the following path: % WINDIR % \ Microsoft. net \ Framework \ v2.0.50727 \ CONFIG \ Browsers, the database contains known compatibility of various devices, such as whether to support cookies, support for those versions of javascript, etc, requests sent from browsers on various devices to the server will carry the Unique user-agent, ASP. NET will automatically compare the user-agent to the database, and then determine the compatibility of the device.
This cookieless function is also applied to Form authentication in ASP. NET. You can configure the cookieless attribute in Authentication Settings in web. config. By default, the Form authentication system determines whether the authentication ticket is saved in a cookie or included in a URL based on the user agent that initiates the request. It is known that mainstream desktop browsers support cookies, however, not all mobile browsers support cookies. Return to the bug in this article again. Some users cannot log on normally because the devices used by these users are ASP. NET is identified as unable to support cookies, although the device itself supports cookies, such as my own handheld device, MOTO Droid X, the user-agent contained in the request sent from the default browser of this device is: User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.3; zh-cn; DROIDX Build/4.5.1 _ 57_DX5-18) AppleWebKit/533.1 (KHTML, like Gecko) H,/4.0 ��o/533.1, after ASP.. NET does not support cookies, so this device cannot log on to our web App normally.
The above investigation shows the cause of Logon failure. The following shows a specific solution.
Solution
After understanding the above Form authentication principles, it is easy to think that the cookie is disabled because the user-agent of the mobile device cannot be correctly identified by the system, there are two solutions:
Solution 1: overwrite the system configuration so that all devices can be recognized as supporting cookies by the system.
Asp. NET provides a mechanism for you to customize system support for certain devices, add the system folder Asp_Browsers in the project, and add the custom configuration file, the following is the configuration file added to solve the above problem.

 


 

The configuration is as follows:
<Browser refID = "Mozilla">
<Capabilities>
<Capability name = "cookies" value = "true"/>
</Capabilities>
</Browser>
 
<Browser refID = "Default">
<Capabilities>
<Capability name = "cookies" value = "true"/>
</Capabilities>
</Browser>
The configuration code above indicates that cookies are supported for all devices, which solves the issue of cookies on some devices.
 
Solution 2: Change the default form settings so that the system no longer determines whether the cookie is supported based on the device
The configuration of Form authentication is contained in the site configuration file. In the configuration of <authentication mode = "Forms">/<forms>, add cookieless = "UseCookies ", the default configuration is UseDeviceProfile, which is a tool device that determines the support of Cookies.
The purpose of the above two solutions is the same, that is, to make the system think that all devices support cookies. The first solution is more flexible, and the second solution is more thorough, you can select an appropriate solution based on the actual situation.
Postscript
Microsoft's cookieless design is good, but this default value is UseDeviceProfile, Which is debatable. Today's browsers are full of flowers, and each browser has its unique user-agent, especially the mobile browser, even in the same browser, different device manufacturers add information to the user-agent to identify the device model and brand, and Microsoft may not frequently update ASP.. NET browser configuration, so there will be a lot of false positives. In the current situation, the system should set the default value to UseCookies, that is, by default, cookies are supported by all browser browsers.

 

From the grape city control technical team blog