Implementation of cookieless sessions

No Cookie Session

In ASP. NET, You can selectively establish necessary session-user contacts without using cookies. Interestingly, except for the following configuration settings, you do not need to change anything in the ASP. NET application to enable Cookie-free sessions.

 
 

  
  
< sessionState cookieless="true" />   
 
 

The default settings of ASP. NET session status are defined in the machine. config file and can be rewritten in the web. config file in the application root folder. You can enable the cookieless session by ensuring that the preceding row appears in the root web. config file. That's it-simple and effective!

<SessionState> nodes can also be used to configure other aspects of session State management, including storage media and connection strings. However, for cookies, you only need to set the cookieless attribute to true to false by default ).

Note that session settings are the application scope settings. In other words, the pages on your site either use or do not use cookies to store session IDs.

Where does ASP. NET Store session IDs when no Cookie is used? In this case, the session ID is inserted to a specific location in the URL. Displays a snapshot of a real site that uses a session without Cookie.

 

Figure 1. Use a MapPoint without a Cookie Session

Assume that you have requested a page similar to http: // yourserver/folder/default. aspx. As you can see from the MapPoint snapshot, the adjacent slashes in front of the resource name are extended to include the brackets filled with the session ID inside, as shown below.

 
 

  
  
http://yourserver/folder/(session ID here)/default.aspx  
 
 

The session ID is embedded in the URL and does not need to be permanently saved anywhere else. Well, not exactly. Consider the following solutions.

You access a page and are assigned a session ID. Next, you clear the address bar of the same browser example, go to another application and start working. Then, you re-type the URL of the previous application and guessed it) to retrieve the session value as you enter.

If you use a cookieless session, when you access the application for the second time, you will be assigned a different session ID, and all previous statuses will be lost. This is a typical side effect of cookieless sessions. To understand the cause, let's further explore the implementation of cookieless sessions.

Implementation of cookieless dialogs

The implementation of cookieless sessions is benefited from the efforts of the following two runtime modules: a standard session HTTP module named SessionStateModule and an executable file named aspnet_filter.dll. The latter is a short Win32 code that acts as an ISAPI filter. The HTTP module and ISAPI filter share the same idea. The difference is that the HTTP module consists of managed code and can only work after ASP. NET and CLR are triggered. Traditional ISAPI filters such as aspnet_filter.dll are called by Internet Information Service (IIS. Both of them intercept IIS events triggered during request processing.

When the first request for a new browser session enters, the session Status Module reads the Cookie-supported settings in the web. config file. If the cookieless attribute of the section is set to true, the module generates a new session ID, which is used to split the URL by filling the session ID in the adjacent position before the Resource Name, use the HTTP 302 command to redirect the browser to the new URL.

When each request arrives at the IIS portal much earlier than it is handed over to ASP. NET), aspnet_filter.dll gets a chance to view it. If the URL embeds the session ID in parentheses, the session ID is extracted and copied to a request header named AspFilterSessionId. Then, rewrite the URL to make it look like the original requested resource and release it. This time, the ASP. NET session status module retrieves the session ID from the request header and continues working through session-status binding.

As long as the URL contains information that can be used to obtain the session ID, the Cookie-free mechanism can work well. However, this may cause some restrictions. These limitations will be described in another article.

1. ASP. NET Cookie: No problem
2. XML in the. NET Framework: internal principle of XmlSerializer
3. XML base class in the. NET Framework: xsd.exe
4. ASP. NET 2.0 Page Status Persistence: ViewState and Control
5. Custom set of ASP. NET 2.0 data binding controls