8.3. Cookie-Based Sessions
Storing the session identifier in a cookie is the most common mode of operation for developers; it is also the default mode of operation for ASP.NET 3.5. Because it follows the programming model as session state in Classic ASP, many developers never need to deal with the cookieless mode of operation. You saw earlier that session state providers ensure that data in the back-end data store is properly partitioned by application. This is important because if you look at the session identifier in use across multiple applications on the same web server, you see that it is the exact same identifier. The application ID-based partitioning is hidden inside of the session state providers.
8.3.1. Sharing Cookies Across Applications
If you write other application code that depends on Session.SessionID, the same value is going to show up in different applications. If your intent is to hook other application logic and data storage off of SessionID, you may want to use a different identifier, such as a combination of authenticated username and application name. The one thing you definitely do not want to do is to come up with a solution that forces creation of a new session identifier in each unique application.
Think about a scenario in which you have multiple applications sitting on the same server. The HttpCookie that the session state feature issues will have the following characteristics:
