October 12th, 2019
I’ve used localStorage before, but the sessionStorage was new to me, so I wanted to know more, and learn about the differences between them.
Why store data locally? The challenge with HTTP as the transportation layer for the web is that it is stateless. That means that when you interact with an application and then refresh the page or close it, its state will be reset. Our login credentials, text fields, settings, and high score would all be blank again. That sounds like a pain!
To avoid this, the state of the application is often stored server side and connected to a user name (cookie). But if we don’t want to force our users to log in or sign up, we can use local storage. And we have two mechanisms within Web Storage to choose from:
sessionStorage(): stores data for the duration of the page session (as long as the browser is open, including page reloads and restores). Data is not transferred to the server, and the storage limit is larger than a cookie.
By keeping keys on the user’s computer we can read it out when the user returns. We could store username or a list of data so that the application doesn’t have to load it from the server every time the user returns, or save states between pages in a payment process for example.
As I wrote this article, I started wondering how a web session actually work. The way I understand it, sessions can be defined as the different states of an application during the time a user interacts with it.
When it comes to web sessions specifically, we can look at them as a data structure that an application uses for storing temporary data. This data is useful only during the time a user interacts with the application, and the session is unique for every user.
We can think of it as a small storage space that is allocated to each user who is interacting with the application; When you enter a web site, you get your own personal locker. You fill it with stuff while you are there, and when you leave, it gets emptied and the contents destroyed (as opposed to the localStorage mechanism explained above).
When we start a new session, we are assigned a key /value pair data structure where we are given a session id (hashkey) to put our data in. We can only access the data in our own session object. The session can be stored on a server or, if it’s on the client side, in the browser. This is where cookies come in.
Cookies A cookie is a text file that is hosted on the user’s computer and is connected to the domain that the website is hosted on. It stores data that has to be sent back to the server upon requests. The expiration duration varies and is normally set from server-side.
Cookies are primarily for server-side reading but can also be read on client-side (localStorage and sessionStorage can only be read on client-side), and its size must be less than 4KB. Cookies can be made secure by setting the httpOnly flag as true. This prevents client-side access to that cookie.
Session (cookies) step by step:
We visit a website for the first time and receive the page and the content along with a session id from the server so that it is able to identify our connection among all the others.
We log in, and our user id is saved to the session. This way we don’t have to log in again every time we make a new request (remember that HTTP is stateless).
Every time we make a request, the session id is sent along with it to tell the server that we are the same user from earlier. The session id is usually sent via cookies.
The server receives the request and looks up the session id in its session data store. If it finds it, it returns the data.
The code is generated, an HTML page is created and the page is filled with our data.
The page is returned to us, along with our session ID.
Without the session id, we would have to log in every time we made a request. That would be a real pain. But sessions keep us logged in as long as we are connected to the server.