Member-only story
When a website supports user accounts, it’s essential to verify that all incoming requests are made by an authorized user. One approach is to include user credentials with each request, allowing the server to authenticate their legitimacy.
However, verifying a password is intentionally slow, meaning the web server would be forced to perform unnecessary work. Additionally, each time credentials are transmitted over the internet, there’s a risk that an attacker could intercept and steal them.
Sessions are designed to solve this problem, allowing the web server to recognize the returning user without rechecking credentials for each request.
When a user logs into a website, the server generates a session ID for that user. This ID is then sent back to the client’s browser in an HTTP response, specifically within the Set-Cookie header. The session ID is stored in a cookie on the client-side. From this point on, every subsequent HTTP request made by the user includes the session ID in the Cookie header.
The cookie containing the session ID is sent along with each subsequent request to the server. When the server receives a request with a session ID, it looks up that ID in its database or memory to recognize the user associated with it. The server doesn’t need to verify the user’s credentials (such…
