Using cookies to store session in ASP MVC

Question

Storing the entire session in a cookie has been standard in Rails for the last few years - is there an easy way to achieve something similar with ASP MVC?

By default, anything in Session / TempData is stored in memory on the server. In web.config this can be changed to an SQL Store / server-side cache. I'd like to be able to have these objects persisted in a cookie.

It looks like I could implement a custom Session-State Store Provider. Is there a simpler approach?

Answer 1

http://msdn.microsoft.com/en-us/library/ms178587.aspx

Answer 2

depends on what kind of data you want to store in the cookie, if you want just to store string, the following code will do:

HttpCookie cookie = new HttpCookie("username","sth");
            cookie.HttpOnly = true;
            cookie.Expires = DateTime.Now.AddMonths(3);
            HttpContext.Current.Response.Cookies.Add(cookie);

Answer 3

You shouldn't use Sessions for this, but Profiles instead. Profiles use cookies to match computers to profiles, etc. The profile key is stored in a cookie, and isn't lost when closing browser etc.

Info here; http://odetocode.com/articles/440.aspx

Answer 4

I would strongly discourage storing the entire session in cookies. I has bad performance implications. Consider this: every request (to every resource) will contain an overhead of possibly stale data that you only need once or twice. Eventually this overhead will hit your users, your bandwidth and your site performance.

Here's an example:

GET / HTTP/1.1
Host: localhost
OtherUsefulHeaders: foo
Cookie: YourSessionState=...

Initial request size is around 200 bytes. Let's say, you add around 100 bytes to your session. Now the size is 300 bytes and overhead is ~30%. You add another 100 bytes, and overhead is 50%. Which means it roughly requires 2x time to send the request and 2x bandwidth.

You should rather look into cookie-based TempData implementation as it has much smaller footprint and actually makes sense.

Answer 5

yes, implement a custom state session-provider. And no, afaik there isn't a simpler approach.

Ps. it isn't as bad as it looks i.e. > half of the odbc sample is writing to the db.

Answer 6

I think it would be much more efficient to just store the session ID (a hash or whatever) in the cookie, and then use that ID to get the session data from memory / database / whatever storage you prefer. Keeping the full session state in a cookie increases bandwidth innecessarily.

Also, keep security in mind: if the cookie contains authentication information or other sensitive data and you're not careful, it can easily be hacked by the user to gain privileges or otherwise mess with your application (encrypting the data sucks too, because then you have to base-64 encode the encrypted data, which further wastes bandwidth and processing time). You should never trust input from the user.