title: Create a New Session ID (seamless ID transfer)
body: <p>So I'm running into an interesting issue implementing session ID rolling after log-in/change of access levels/etc.</p>
  
  <p>On log-in I'm currently trying to generate a new session ID using the SessionIDManager, however this only changes the cookie header, it doesn't swap out the session in HttpContext, so as I add additional details to the session (various details to bind the user to the session ID), they immediately get lost (not to mention the old session gets abandoned).</p>
  
  <p>To prevent session hijacking (by storing primary non-SSL communication) and session fixation, we should generate a new Session ID upon log in, but Microsoft doesn't seem to allow you to do that (grr, so many read-only variables and sealed classes with no constructors). I could just migrate all data in the backend SQL, but that seems a bit "dirty hack".</p>
  
  <p>Any ideas on how to properly do this?</p>
  
  <p>Edit: </p>
  
  <p>Implementations I've found:</p>
  
  <pre><code>Session.Abandon();
  Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
  </code></pre>
  
  <p>Session still is the old session, so on next page, all changes are lost.</p>
  
  <p>SessionIDManager doesn't return a session object after SaveSessionID, so I cannot add details to the session I just created. On the next page load I can, but the old session is now inaccessible (and abandoned, but even if it wasn't abandoned...).</p>
  
  <p>HttpContext.Session is read only, even if it wasn't, HttpSessionState doesn't have a constructor.</p>
  
  <p>Edit 2:</p>
  
  <p><a href="https://stackoverflow.com/questions/2402312/session-fixation-in-asp-net">Session Fixation in ASP.NET</a></p>
  
  <p>Apparently session fixation and hijacking have been talked about before here, with the answer being "Microsoft doesn't seem to care", with a poorly implemented two-phase fix.</p>