Cookie Less Session in ASP.NET
Published Sep 03 2024 10:04 PM 1,021 Views
Microsoft

Introduction:

 

We, as developers, are aware of the sessions and cookies being used as few of the State management techniques in Asp.NET applications. In case of cookies, session IDs are placed in cookies and gets validated every time requests reach to server for execution. This, of course, keeps the URL tidy and very easy to understand the navigation. But here is an interesting scenario and many of us might have used this as well, which is CookiesLess Session.

 

Traditionally, session IDs are stored in cookies. However, with cookieless sessions, the session ID is embedded directly in the URL, enabling session tracking even when cookies are disabled.

 

How Cookieless Sessions Work

When using cookieless sessions, ASP.NET modifies URLs by appending the session ID. For example, a URL might look like this: http://stackoverflowwebapp.com/(S(klnc3sshuaf3ngm3ihnpch2v))/home.aspx.

 

The session ID is embedded between the application name and the file path. This ensures that the session state is maintained as long as the user follows the links provided by the application.

 

Let’s see how it’s done.

To enable cookieless sessions, you need to set the cookieless attribute to true in the sessionState element of your Web.config file:

 

<configuration>

  <system.web>

    <compilation targetFramework="4.7.2" />

    <httpRuntime targetFramework="4.7.2" />

          <sessionState mode="InProc" cookieless="true" regenerateExpiredSessionId="true" timeout="30" />

  </system.web>

 

I did the repro for this and I could see the sessionID being sandwiched between my domain and the page with an (S). If the SessionID is tampered then it will regenerate the same. 

 

PradeepSharma_0-1725368860942.jpeg

 

 

By looking at this, many of the users might get confused as the URL does not look familiar. But it does the work. So we are able to apply the CookieLess Session in our application. 

 

It was easy to configure, wasn't it? However, it does come with some trade-offs.

 

Cautions

Cookieless sessions have certain security implications. Since the session ID is part of the URL, it can be shared inadvertently if a URL is copied and shared with others. To mitigate this risk, it's advisable to use SSL to encrypt communication between the client and server and consider setting regenerateExpiredSessionId to true to avoid session reuse.

 

 

So, considering the above, CookieLess sessions are to be implemented in very specific scenarios not every time. Please refer to the official documentation for this.

https://learn.microsoft.com/en-us/dotnet/api/system.web.sessionstate.httpsessionstate.iscookieless?v...

Co-Authors
Version history
Last update:
‎Oct 01 2024 07:34 AM
Updated by: