P
PradeepSharma
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:
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 tempered then it will regenerate the same.
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.
Security Considerations
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. This can lead to session hijacking. 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.
HttpSessionState.IsCookieless Property (System.Web.SessionState)
Continue reading...
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 tempered then it will regenerate the same.
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.
Security Considerations
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. This can lead to session hijacking. 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.
HttpSessionState.IsCookieless Property (System.Web.SessionState)
Continue reading...