For HTTP as far as I understand are two ways to store data belonging to a client and bring some kind of state into a otherwise stateless Browser-webcontainer-connection: 1) Data stored in cookies on the client-side - or 2) A session ID stored in a cookie and the associated data stored in a webcontainer on the server-side. When I compare these two possibilities I can't come up with a reason, why one should go the first way. But still, when I look at my browser's cookies, I see a lot of data stored in them.
- A webcontainer (like tomcat) can store arbitrary data together with a session id - A cookie is quite limited in size.
- Cookies are more vulnerable, since they are stored on the client's side. Keep data on the server-side is, as it looks for me, just more secure.
- Both, cookies and webcontainer-sessions, can define expiration dates.
- Both, browser and webcontainer, persist their data over restarts.
Can anyone come up with a scenario where the use of cookies for storing session data has benefits or is even necessary?
The problem with relying solely on session is that in order to limit the server's memory usage, the session data has to be purged after some time, for example 20 minutes is the default of ASP.NET.
Thus, if the users of your site have to log in and you want to give them an option of "remember me", your users will be logged out after a period of inactivity if you use the session for that purpose.
The simplest way to implement this would be to store an encrypted cookie with a distant expiration date, which would let the user authenticate at later times.
Having written that, in order to allow users to end their sessions remotely, sites like Gmail and Facebook don't rely solely on a cookie value for authentication, but they are probably using a special store for those sessions and not general purpose session.