HTTP (Hypertext Transfer Protocol) is how data is delivered and exchanged on the World Wide Web. HTTP is also stateless, which means that a user’s state is not preserved or “remembered” from page to page. This is problematic if you want your app to display different information depending on a user’s profile. One example of this could be an e-commerce website, where you want to keep track of the items in a shopping cart for all your different users. It would be very frustrating for your users to add five items to their cart, go to the next items page and then all of a sudden lose all their carefully picked cart items. The e-commerce store owner just lost a potentially big sale!
So, if HTTP is stateless how can apps remember a user’s state? Enter Sessions and (Browser) Cookies
What is a (Browser) Cookie?
Cookies are key-value data pairs that are stored in the user’s browser (hint: users can access them!) until they reach their specified expiration date. You could store shopping cart information or even passwords there, but that would be a really bad idea.
But why should I not store passwords?
Sensitive information (like passwords) should not be stored in a cookie as people could access that information to then manipulate it and potentially commit fraud.
Ok then why should I not store shopping cart information?
Storing information that needs to be persisted across browser sessions (like shopping carts) shouldn’t be stored in a cookie as a user could clear their cache and lose their shopping cart information.
If you shouldn’t store passwords or shopping cart information in a cookie, then why are we talking about cookies? What are we supposed to store there? Enter Sessions.
What is a Session?
A session represents all the things that a user does (and you have chosen to remember) usually until the browser window is closed. Think about this, you log into your Amazon Prime Account, add some items to your shopping cart, make a purchase, and then log out. All those pages that you visited before logging out were part of the same session.
So What is the relationship between a Session and a Cookie?
Rails stores a secure and encrypted cookie on the user’s browser containing their session hash. This session hash expires when the browser is closed.
Visually, this is how the session is set (usually in your users_controller):
Set a session:
session[:user_id] = user.id
End a session:
session[:user_id] = nil
Visually, this is how you retrieve information about a user through a session (usually in application_controller)
Retrieve the current user, or create a new one depending on whether a session already exists:
@user = User.find_by(id: session[:user_id]) || User.new
Find out if the user is logged in:
!!session[:user_id]
At this point you may be wondering whether a session and a cookie are the same thing or why we need both a session and a cookie to maintain information.
Well, for starters cookies are only stored on the client-side (on the users browser). A Session key gets stored on the client (through the cookie), and the Session gets stored on the server. This should make sense - the server has the session information (how many items a user added to their cart for example), but for the user to access that information, we need them to use a key, this key would be the unique session id, which is stored on the user’s computer and returned with every request to the server.
Another difference is that the cookie expires depending on the lifetime you set for it, but a Session ends when a user closes his/her browser or when you clear it (like for example when a user logs out)
Lastly, the maximum cookie size is 4KB, however in a session you can store as much data as you like.
Top comments (0)