I'm a product engineer at Bonus.ly, Recurse Center alum, and creator of Hackterms. I am happiest when I'm working on delightful and impactful tools for my users. In my free time, I run & write music.
I've written apps with sessions and cookies, and seem to figure it out just enough to get it to work, but the connection between sessions and cookies still baffles me. I've had it explained to me probably a dozen times and it just won't click. For example, both expire. Why?
I'm a product engineer at Bonus.ly, Recurse Center alum, and creator of Hackterms. I am happiest when I'm working on delightful and impactful tools for my users. In my free time, I run & write music.
So, I get that a session gets created server-side and a cookie gets placed client-side. The cookie has an ID that authenticates you to the server so you don't have to login. Is the session data stored in the session or the cookie? Is it fetched from the server every time you need it? Does the session expire? Does the cookie expire? How are cookies shared securely? I realize this is a lot of questions, but I feel like I'm fundamentally missing the underlying process.
A cookie is just a particular type of HTTP header: Cookie:. Cookie were invented to store a little bit of information sent back and forth between stateless clients and servers (HTTP holds no state).
So, now you have this header where you can store stuff into: the list of items you added to your cart, a username, whatever. Cookies have no actual knowledge of what they carry.
In addition to the actual data, a cookie has a bunch of optional metadata (attributes): expiration date, path, domain, security, http only and others.
There's a bit of a misplaced naming convention because technically a "session cookie" is a cookie that dies after the user has finished their own session (closed the tab or the window of the browser). These cookies do not have an expiration date, which signals the browser to delete them after the user's session is finished.
Unfortunately, because we're programmers and we're trash at naming things, other people started using the words "session cookie" also to identify the particular set of value and attributes to recognize a user's session against a webserver in a span of time. To make it simple: that thing that keeps you identified to a single website even when you close the browser, turn off the computer, come back two days later, reopen the browser and voila, you're still known by the server.
This is not magic, it's just using a couple of tricks to overcome the fact that HTTP is stateless.
Let's go over the simplest scenario, using a session cookie to login. You go over website.com for the first time, type username and password, hit submit and then the server (other than checking the credentials) does one particular thing. Adds the following header to their HTTP response:
Set-Cookie: token=supersecret; Expires=Wed, 19 Nov 2019 12:00:00 GMT
What this tells the browser is the following: store a cookie, for website.com, with these values (token=supersecret) until a year from now.
In addition to sending the cookie to the client, stores somewhere (usually a database, but not necessarily) a sort of key value to know that this particular token is associated to the newly identified user.
Then you go about your business. The nextime you go to website.com the browser checks its storage, see it has a cookie, sends it with the HTTP request. The server verifies it's still valid and then lets you in.
Once the cookie expires, the server will bounce you :)
The identification, the storage of the token on the client and the identifying info on the server is what constitutes the concept of "session".
This is a way to build state on top of a stateless protocol.
I'll try to answer your questions now:
Is the session data stored in the session or the cookie?
You can, but IMHO you shouldn't store the actual session data in the cookie, you should store an identifier and the data in a temporary store (a cache) or a persistent one (a database)
Is it fetched from the server every time you need it
It's the client that keeps sending to the server the cookie everytime you hit a URL. Keep in mind that HTTP is stateless, so the server has no idea that you are the same user that asked for a page two seconds ago.
Does the session expire?
So, if the session is stored in the cookie, it will disappear when the cookie expires. If you store it on the server in a time limited key in a cache, the cache server will remove it for you. If you store it in a database, make sure your server framework has the ability to clean up stale sessions.
Does the cookie expire?
Yes
How are cookies shared securely?
The cookie specification has at least a couple of countermeasures: Secure and HttpOnly. The first one means the cookie can only be transmitted over HTTPS, the second one will make the cookie invisible to JavaScript. A newer option is to set the SameSite attribute to prevent cross site attempts to steal the cookie
Hope this helps! Let me know if you have any more questions!
I'm a product engineer at Bonus.ly, Recurse Center alum, and creator of Hackterms. I am happiest when I'm working on delightful and impactful tools for my users. In my free time, I run & write music.
Thank you so much! This was a seriously fantastic explanation at just the right level of complexity. I'm going to go over it a couple of times when I get home from work, but here's the ELI5 version, if I understand correctly: a cookie is a special HTTP request header that contains a secret string and acts like a sort of VIP pass. Every time we send a request to the server, as long as the cookie hasn't expired yet, this "pass" is shown to the server, which grants us user data without having to supply user authentication info.
When we talk about session data, is that just the data that gets returned from the server? Is it a subset of all user data?
When we talk about session data, is that just the data that gets returned from the server? Is it a subset of all user data?
If you store actual session data related to the user inside the cookie, then the session data is that. It's not a great idea because if the cookie gets spoofed the third party will know information about your user.
If instead you only store the token (the VIP pass) in the cookie, the session data resides on the server and it will be used to populate the next HTML response (eg. Hi Max, access your profile) or any other response format the client ask for. That's when the info about the user gets sent back to the server.
You, in your application, decide what "user data" is. It could be just a name, it could be anything attached to a single user
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've written apps with sessions and cookies, and seem to figure it out just enough to get it to work, but the connection between sessions and cookies still baffles me. I've had it explained to me probably a dozen times and it just won't click. For example, both expire. Why?
Are you talking about browser side session storage or server side session storage?
So, I get that a session gets created server-side and a cookie gets placed client-side. The cookie has an ID that authenticates you to the server so you don't have to login. Is the session data stored in the session or the cookie? Is it fetched from the server every time you need it? Does the session expire? Does the cookie expire? How are cookies shared securely? I realize this is a lot of questions, but I feel like I'm fundamentally missing the underlying process.
Hi Max,
I'll try to give you an answer.
A cookie is just a particular type of HTTP header:
Cookie:. Cookie were invented to store a little bit of information sent back and forth between stateless clients and servers (HTTP holds no state).So, now you have this header where you can store stuff into: the list of items you added to your cart, a username, whatever. Cookies have no actual knowledge of what they carry.
In addition to the actual data, a cookie has a bunch of optional metadata (attributes): expiration date, path, domain, security, http only and others.
There's a bit of a misplaced naming convention because technically a "session cookie" is a cookie that dies after the user has finished their own session (closed the tab or the window of the browser). These cookies do not have an expiration date, which signals the browser to delete them after the user's session is finished.
Unfortunately, because we're programmers and we're trash at naming things, other people started using the words "session cookie" also to identify the particular set of value and attributes to recognize a user's session against a webserver in a span of time. To make it simple: that thing that keeps you identified to a single website even when you close the browser, turn off the computer, come back two days later, reopen the browser and voila, you're still known by the server.
This is not magic, it's just using a couple of tricks to overcome the fact that HTTP is stateless.
Let's go over the simplest scenario, using a session cookie to login. You go over website.com for the first time, type username and password, hit submit and then the server (other than checking the credentials) does one particular thing. Adds the following header to their HTTP response:
Set-Cookie: token=supersecret; Expires=Wed, 19 Nov 2019 12:00:00 GMTWhat this tells the browser is the following: store a cookie, for website.com, with these values (token=supersecret) until a year from now.
In addition to sending the cookie to the client, stores somewhere (usually a database, but not necessarily) a sort of key value to know that this particular token is associated to the newly identified user.
Then you go about your business. The nextime you go to website.com the browser checks its storage, see it has a cookie, sends it with the HTTP request. The server verifies it's still valid and then lets you in.
Once the cookie expires, the server will bounce you :)
The identification, the storage of the token on the client and the identifying info on the server is what constitutes the concept of "session".
This is a way to build state on top of a stateless protocol.
I'll try to answer your questions now:
You can, but IMHO you shouldn't store the actual session data in the cookie, you should store an identifier and the data in a temporary store (a cache) or a persistent one (a database)
It's the client that keeps sending to the server the cookie everytime you hit a URL. Keep in mind that HTTP is stateless, so the server has no idea that you are the same user that asked for a page two seconds ago.
So, if the session is stored in the cookie, it will disappear when the cookie expires. If you store it on the server in a time limited key in a cache, the cache server will remove it for you. If you store it in a database, make sure your server framework has the ability to clean up stale sessions.
Yes
The cookie specification has at least a couple of countermeasures:
SecureandHttpOnly. The first one means the cookie can only be transmitted over HTTPS, the second one will make the cookie invisible to JavaScript. A newer option is to set theSameSiteattribute to prevent cross site attempts to steal the cookieHope this helps! Let me know if you have any more questions!
Thank you so much! This was a seriously fantastic explanation at just the right level of complexity. I'm going to go over it a couple of times when I get home from work, but here's the ELI5 version, if I understand correctly: a cookie is a special HTTP request header that contains a secret string and acts like a sort of VIP pass. Every time we send a request to the server, as long as the cookie hasn't expired yet, this "pass" is shown to the server, which grants us user data without having to supply user authentication info.
When we talk about session data, is that just the data that gets returned from the server? Is it a subset of all user data?
Your description is correct.
If you store actual session data related to the user inside the cookie, then the session data is that. It's not a great idea because if the cookie gets spoofed the third party will know information about your user.
If instead you only store the token (the VIP pass) in the cookie, the session data resides on the server and it will be used to populate the next HTML response (eg. Hi Max, access your profile) or any other response format the client ask for. That's when the info about the user gets sent back to the server.
You, in your application, decide what "user data" is. It could be just a name, it could be anything attached to a single user