Currently our web application uses server-sided sessions. Because of the large amount of memory usage, we want to switch to cookie-based sessions. I have been thinking about several ways:
My first idea was to give the client two cookies:
SessionID (a hash) and
SessionData (the encrypted data). The
SessionID will be used to look up a decryption key for
SessionData in an in-memory hashtable.
Because only decryption keys are stored on the server, this should wind up being less memory usage. However it still uses some memory, and the CPU load is increased due to encryption/decryption on every request.
It'd also make the session cluster-dependant, with no graceful failover possible.
My second idea was similar to the fist, but instead of looking up a decryption key in a cache, I'd use a salted version of
SessionID to decrypt
The upside is that there wouldn't be any in-memory cache or hash table anymore, and that session would be cluster-independent if the salt is the same for all clusters.
However, the tradeoff is that it's much less secure due to a potential danger of decrypting or modifying the
SessionData cookie, and that the CPU load is increased due to encryption/decryption on every request.
Is there a better way to go about this problem? Or a way to modify one of these ideas to be a little more palatable?