Session (at least ASP.NET session) and ViewState are pretty different though. ASP.NET session is on the server, and looked up via a key fom the session cookie (sent to the client). ViewState is sent to the client to allow...well to allow ASP.NET pages to be really horrible and heavy, but also to allow it to know what the 'previous' value for controls was so it can raise change events etc.. Serializing ASP.NET session out to the client is definitely weird, and would not be a normal thing to do. Is rails 'session' being discussed more analogous to ASP.NET viewstate?
nope, I think that rails session sounds probably like ASP.net session. At any rate, rails session is like PHP session (i am not familar with asp.net).
But yes, the default Rails implementation does not store the session on the server but a key in a cookie. Although you can optionally do that, storing the actual session data in the rdbms, or other server-side places. But the default Rails implementation, yes, actually stores the session info itself in cookies.
One of the benefits of this is, when you've scaled out/load balanced your app servers to multiple instances, they don't need to share a session store somewhere, they each get the entire session via cookie. There are also other disadvantages, including with synchronization.
But also including that your session data is now visible to the client when it wasn't before. So, yeah, encrypting the data is one way to change the trade-off calcuation and make it work for more (but not all) apps/use cases, why not?
It actually doesn't increase the complexity much. If you're storing session data in cookies to begin with, you already needed to crypto sign them, to avoid tampering. If you're involving crypto in there anyway, and a secret key anyway, might as well (as a configurable option, sure; which is the default configuration, why not) tell the crypto library to encrypt+sign/decrypt+verify instead of just sign/verify, why not.
