Sessions and cookies — how Django remembers a logged-in user

Every HTTP request (from the system design domain's HTTP/APIs lesson) is independent — the server has no built-in memory of any previous request from the same browser. Without something bridging that gap, there'd be no way to say "this request and that earlier request came from the same logged-in user" at all; each request would look identical to the server whether it came from a logged-in Ada or a stranger who'd never logged in.

A cookie is a small piece of data the server asks the browser to store, which the browser then automatically attaches to every subsequent request to that same domain. This is the actual bridge across HTTP's request-to-request amnesia: the cookie itself doesn't have to contain the user's data — it just has to contain something unique enough to identify which stored session belongs to this browser, on the server's side.

Django's session framework stores session data server-side — by default, in a database table (django_session) — and the cookie (sessionid, set by SessionMiddleware from the middleware lesson) holds only a random, unguessable key pointing at that row, never the actual data. request.session behaves like a dict, and reading/writing to it transparently reads and writes the corresponding database row behind the scenes. This server-side storage is deliberate: since the cookie only holds a reference, not the actual data, there's nothing sensitive for someone intercepting or inspecting the cookie itself to actually read.

The auth-and-permissions lesson stated that AuthenticationMiddleware sets request.user by reading the session — this is the literal mechanism: the incoming request's sessionid cookie is looked up, the corresponding session row is loaded (this is what SessionMiddleware does), and AuthenticationMiddleware finds a stored user ID inside that session data, looks up the actual User row, and attaches it as request.user. Every request that "remembers" a logged-in user is doing exactly this lookup chain — cookie, to session, to user — on every single request, not once at login and then somehow remembered afterward.

Cookies are the mechanism specifically because browsers handle attaching them automatically — no JavaScript has to manually re-send an identifier on every request. HttpOnly (which Django sets by default on the session cookie) prevents JavaScript from reading the cookie's value at all, which matters directly for the web security lesson's XSS coverage: even if malicious JavaScript gets injected into a page, it can't read and exfiltrate the session cookie if HttpOnly is set. Secure ensures the cookie is never sent over an unencrypted connection, protecting it from being intercepted in transit.

A session doesn't last forever by default — SESSION_COOKIE_AGE controls how long a session stays valid, and an expired session's cookie is simply treated as if it doesn't exist, sending the request back to being anonymous (AnonymousUser, from the auth lesson) even if the cookie is technically still present. This is a genuine security/convenience trade-off: a longer expiration means users stay logged in longer without re-entering credentials, but also means a stolen or leaked session cookie stays exploitable for longer.

logout() doesn't just "forget" the user client-side — it deletes the session data server-side (or at minimum invalidates the reference) and clears request.session, which is exactly why the same sessionid cookie value can't be reused to log back in after a logout; the row it used to point at is gone. This is why session-based logout is more robust than something purely client-side would be — the invalidation happens on the server, which the client's browser has no ability to undo.