Sessions: how login stays logged in

The session pattern

Here is the standard login flow, built entirely from pieces you already know:

1. You submit the login form: a POST /login (lesson 5-3) with your email and password in the body.
2. The server checks the password. If it is right, it invents a random session ID like abc123 and stores a record on its side: "abc123 = user 42, logged in at 14:02".
3. The response carries Set-Cookie: session=abc123; HttpOnly; Secure.
4. Every later request from your browser automatically includes Cookie: session=abc123. The server looks up abc123 in its session store, finds user 42, and treats the request as yours.
5. Logging out deletes the server-side record and clears the cookie. The ID means nothing anymore.

Notice what is not in the cookie: your password, your name, anything readable. The cookie is only a claim ticket. All the real information stays on the server, and the random ID is the key to it. Anyone who steals the ticket can impersonate you though, which is why the attributes matter: HttpOnly keeps scripts from reading it, and Secure means "only send this over encrypted HTTPS", which is one of the reasons unit 7 exists.

The server's session check

Step 4 of the flow above, in code. The sessions dict is the server-side store.

sessions = {"abc123": "user 42", "zzz999": "user 7"}

for cookie in ["abc123", "deleted", "zzz999"]:
    if cookie in sessions:
        print("session", cookie, "->", sessions[cookie])
    else:
        print("session", cookie, "-> 401 Unauthorized (unknown session)")

Output

session abc123 -> user 42
session deleted -> 401 Unauthorized (unknown session)
session zzz999 -> user 7

Reading the lookup

• if cookie in sessions: is the entire authentication check on every request, which is why session stores are built for fast lookups.
• The deleted value has no entry, and the reason does not matter to the server. Perhaps the user logged out, perhaps the ID expired, and either way there is nothing to look up.
• This lookup is why logging out works instantly. The server deletes its side of the record and the same cookie value becomes worthless, even though the browser may still be holding it.
• 401 Unauthorized from lesson 4-3 is exactly what real apps answer when the session cookie is missing or unknown, and the browser then shows the login page.
• Notice the cookie value never appears in the output as anything meaningful. It is an opaque key, so the store could map it to a user, a role, and an expiry without the browser learning any of it.

Why session cookies use HttpOnly

It stops the page's JavaScript from reading the cookie, so a script injected by an attacker cannot steal the session.

The session ID is a claim ticket, and whoever presents it is treated as you. That makes it the single most valuable string in the browser.

If malicious JavaScript sneaks into a page, an attack called XSS, it will try to read cookies and send them to the attacker. HttpOnly makes the cookie invisible to all page scripts while the browser still attaches it to requests, which cuts off that theft route without breaking the mechanism.

The attribute costs nothing, because no legitimate page script needs to read a session ID. Anything that needs to know who the user is can ask the server, which already has the lookup table.

After clearing cookies

From the server's point of view you are logged out.

Your browser no longer sends the Cookie: session=... header, so the server has no session ID to look up and treats the request as a stranger's.

The server-side session record may still exist, and probably does until it expires, but nothing connects your browser to it anymore. The server only ever recognized you by the cookie your browser attached.

This is also why "clear your cookies" is the classic fix for a broken login state. A stale or corrupted session cookie makes every request fail in confusing ways, and discarding it forces a clean login rather than trying to repair the old one.