Iteration 1: Objects and Operations That Spam Requests

While the bulk of the state that persists across requests belongs in the database and is accessed via Active Record, some other bits of state have different life spans and need to be managed differently. While the Cart itself was stored in the database in our Depot application, knowledge of which cart is current was managed by sessions. Flash notices were used to communicate messages such as “Can’t delete the last user” to the next request after a redirect and callbacks were used to extract locale data from the URLs themselves.

In this lesson, we’ll explore each of these mechanisms in turn.

Rails sessions

A Rails session is a hash-like structure that persists across requests. Unlike raw cookies, sessions can hold any marshallable objects, which makes them ideal for holding state information in web applications. For example, in our store application, we used a session to hold the shopping cart object between requests. The Cart object could be used in our application just like any other object, but Rails arranged things so that the cart was saved at the end of handling each request. More importantly, it ensure that the correct cart for an incoming request was restored when Rails started to handle that request. Using sessions, we can pretend that our application stays around between requests.

That leads us to an interesting question: Where exactly does this data stay between requests? One possibility is for the server to send it down to the client as a cookie, which is the default for Rails. It places limitations on the size and increases the bandwidth but means that there is less for the server to manage and clean up. Note that the contents are encrypted by default, This means that users can neither see nor tamper with the contents.

The other option is to store the data on the server. It requires more work to set up and is rarely necessary.

• First, Rails has to keep track of sessions. It does this by creating a default 32-hex character key (which means there are 16^32 possible combinations). This key is called the session ID, and it’s effectively random. Rails arrange to store this session ID as a cookie with the key _session_id on the user’s browser. Because subsequent requests come into the application from this browser, Rails can recover the session ID.

• Second, Rails keeps a persistent store of session data on the server, indexed by the session ID. When a request comes in, Rails looks up the data store using the session ID. ...