Today I am going to start a series of posts describing various approaches to managing http sessions with a Ruby on Rails application. Http sessions are valuable for managing state when using a stateless protocol like http. The emphasis here will be on moving toward the most resilient and scalable solutions. For more detail on sessions and Rails I strongly recommend you purchase Agile Web Development with Rails
Sessions can contain any objects which can be marshaled (think serialization if you are used to other languages). Rails provides numerous ways to persist the session objects. The default in Rails 2.0 is to send it via a cookie to the client. Because the session is hash-like, multiple objects may be stored in the session. The size limit of cookie based session objects is 4K total.
Because the data in the session is passed with every http request from the client to the server, this can cause an increase in bandwidth usage compared to alternative approaches (discussed in the next posts). Also, even though the cookie contents are signed, they are unencrypted by default. So no secure data should be stored in the session when using the cookie_store.
If your session data is very small and the data is not sensitive, then using the cookie_store can be very effective. However, for many web applications this is not the case and fortunately Rails provides some effective solutions.
You can change the session defaults in your controllers by overriding them with the session declaration in a controller.
[...] Rails Session Management Howto, Part I Aug 30 [...]