Sessions and Cookies, a Quick Overview

What are Sessions and Cookies?

Getting straight to the point, sessions and cookies are used to store data when working in the web. Here, I intend to introduce the concepts behind these technologies in a programming language agnostic environment.

Sessions and cookies are a way to track state. State is a some data that describes something’s current condition. For example, think of a traffic light: at one time, it can be red, green, or yellow. Which color it is currently showing is it’s state. Without some method of keeping track of state, websites wouldn’t be able to, say, show you a unique shopping cart filled with your hand picked items. Now, since I imagine you have seen an website that does this before, there is some way of storing state. However, the technology that is the backbone of the modern Internet, HTTP, however, does not keep track of data like state.

Well, what does HTTP do? The good thing is, HTTP is a well built acronym, and the full meaning says all. HTTP stand for HyperText Transfer Protocol, and the word we are looking at here is transfer. All HTTP is meant to do is move data, not change or read it. In fact, by itself, HTTP can’t even keep exact details on who asked for what page. Any sort of added data has to be handled by some other technology. And the simplest technology we use to keep track of this data? Cookies.

Web Cookies

Cookies may have a bit of a bad rap, mainly because of tracking cookies. But really, a cookie is just a bit of plaintext (often in JSON format) that is stored on your browser. Further, it has a domain and path it is associated with (like www.exampledomain.com/path),  and can expire (that is, delete itself), after a certain period of time. It can store most anything the developer wants, such as site preferences, or a shopping cart’s content. Honestly, a cookie is some text stored in your browser, and many are more mundane than tracking cookies that monitor your activities. In fact, most browsers allow you to look at your cookies. So, for example, here is how you can view your cookies in Chrome.

How Cookies Work

Anyway, on to how cookies are actually used by browsers and servers. Basically, when a user looks up a website, HTTP sends a request to see a page. Eventually, a server containing that page will respond, and if configured to do so, sends a cookie to hold data. Usually, I’ve seen cookies content set server side, though it is possible to modify them from the client (here, the browser). Now, this is where the cookie’s domain and path are important. A cookie, if it exists, will be resent every time a page is requested, but only to the page with the same domain and path. A cookie for google.com won’t be sent to wikipedia.com. And lastly, if the cookie is set to expire, it will eventually delete itself after a given time.

The Flaw in the Cookie

Cookies are great and all, but they have one major problem: they are not super secure. Because they store data as plain text on the browser, they don’t really work well for secure data. Like passwords. Plus, as mentioned earlier, you can easily view the contents of most cookies, unfiltered, with built in browser tools. How do we deal with this? Enter, sessions!

Sessions

Picture of the Session Monster, an orange monster (in the style of Sesame Street's Cookie Monster), with a cookie in his hand
It’s the Session Monster, the adorable totally not copyright infringing parody, who only wants your sessions!

Sessions are a bit different than cookies, in that instead of storing data on the client (your browser), they store data on the server, usually in a database, and a session ID is sent to the client to be stored. Usually, this session ID, just a number identifying who you are, is stored in a cookie. So really, many of the same rules apply. Yay! We’ve reduced the problem down to a previously solved one! High fives all around! Anyway, whenever the browser requests a page from a server, the cookie with the session ID is sent to the server, and the server responds with an appropriately formatted web page.

There are two major implications for storing the actual data server side. First, it is more secure, well, as secure as the server it is set up on. Sensitive data like passwords are not out in the open on the browser. Second, all modifications to the data, ultimately, are handled server side. When using sessions, the focus should be more on transferring data properly to the server so that it can be stored properly.

Conclusion

Anyway, I think that sums up my language agnostic intro to sessions and cookies. Hopefully, in the long term, I’ll cover a bit on HTTP, and maybe cookie/session stealing and why it’s bad. Until next time, so long, and good night!

Also, here is a quick summary on sessions and cookies:

  • Cookies
    • Store data on the client (usually a browser)
    • Store data in plain text, usually as JSON
    • Can be set to expire after a certain period of time
    • Have a domain and route (such as www.exampledomain.com/route)
    • Are sent to the server every time a request is made to the associated domain and route
  • Sessions
    • Store data mainly server side
    • Only a session ID is stored client side, usually as a cookie
    • Can be set to expire
    • When a request is made, the relevant cookie is sent with the session ID, and the appropriate data is retrieved from a server side database and sent back by the server

Leave a Reply