So, I’ve always incorrectly thought that somehow, the cookie stored in asp.net was somehow tied to the Session provider in asp.net. Turns out I’m wrong. This came up because I was discussing with another engineer whether we need to bother with a Session provider since we do not use Session in our web application. That is, we don’t ever store information by saying something like:
Session[“MyKey1”] = “MyShoppingCartInfo1”;
My assumption was that somehow, the Cookie planted on the client’s browser was in lock step with the IIS server through Session and that even if we did not store Session data, we still had to hook up a Session Provider. Wrong I am.
I emailed Stefan Schackow, a Microsoft employee who is an expert on all things secure around IIS and ASP.NET and he assured me of this fact. In fact, I’m going to quote (with his permission) what he told me.
If your app doesn’t use Session anywhere then it doesn’t matter. We don’t internally rely on session state for anything. You could literally pull the SessionStateModule out of the configured httpModules list and it would have no effect.
This is a point of confusion for developers because the term “session” is overloaded. For some of the EJB platforms “session” implies things like authenticated sessions. But for ASP.NET session is just a bag of data – if your application doesn’t use it, you can completely ignore the feature.
I hope this helps you if you were misguided like I was.