Web developers use sessions almost everyday, but not all know how it really works, this post will cover some important questions about web server sessions, so it would be easier to debug your session problems.
No TL;DR for you today, sorry, but here’s a table of contents.
What is a web server session?
Let’s take an example like when you log into an application, the server hands the session information to the backend language, e.g. PHP, so that it stores that you are logged in (stores your user ID that is in the database, for example) in the session so that you don’t have to login at every request.
What is a web server session?
A session in general is some data that’s shared between two or more devices.
A web server session is used to exchange connection-specific temporary information between the server and the browser for the duration of the browsing session.
A web server session is used to exchange connection-specific temporary information between the server and the browser for the duration of the browsing session.
A session is used to tell the server which client has sent the request so it knows what data it will send to that client.
What is a web server session, really?
A web server session is some data structure that usually stores key-value pairs of data that’s stored and managed on the web server, it can be stored in a file, cookie, database or other storage options (including the RAM).
That data structure, say, a file, is created for each user and stores whatever is the backend (PHP, Python, etc..) tell it to store, but most importantly it carries the session ID, that’s unique for each connection (browser session).
How exactly does that “exchange” happen?
As soon as you hit a web page, the server receives your request for that particular page, it sends you the page content along with your “randomly” generated session ID (usually in a cookie).
That cookie carries your session ID back and forth between all your requests for the current browsing session so that the server knows who you are and persists your information across subsequent requests.
So basically that sookie is like a fingerprint for your browser for the current session.
 |
The cookie name is different between languages and frameworks (In this image it’s the default Laravel session cookie name) , you can set its name to your liking, what matters is that its value is the session ID that server had assigned to your browser at that time.
Let’s take an example like when you log into an application, the server hands the session information to the backend language, e.g. PHP, so that it stores that you are logged in (stores your user ID that is in the database, for example) in the session so that you don’t have to login at every request.
 |
| Session exchange diagram |
So, how does the server know which session file is mine?
At every request, your browser sends back your session ID (in the form of a cookie or in URL parameters, whichever is the method) to the server along with the request to the web page to tell the server that it’s really you from before.
The server compares the session ID you just sent it with the session IDs it has stored for all the clients and it gets your specific information and makes it available to your backend programming language to process the request (get your information from the database using the user ID in your session and feed that into you a user-specific profile page, for example) and send you back your requested page, and your session ID cookie with a Set-Cookie header.
This goes on until the session is destroyed;
Logging out, closing the browser or a timeout, for example, are all session destroyers.
When does this “Session ID” get created?
In general, your session is created when there’s a mismatch between the session IDs that are exchanged between the browser and the server, including missing ID from either ends.
- With the first page you open in a web application, the request for that web page is sent without the session ID cookie, so the server knows that it should start giving you a name (session ID) which you use after that to tell it that it’s the same you.
- You open another browser (or use a new private window), explaining why in a moment.
- The session is deleted on the server.
No comments:
Post a Comment