Sessions & Cookies: Real State Across Stateless Requests

Building a Web Framework

Chapter 6 · Sessions & Cookies: Real State Across Stateless Requests

Every request this course has built so far starts from nothing — a fresh environ dict, a fresh Request, no memory of anything a previous request did. That's genuinely how HTTP works: each request really is independent. A shopping cart, a "logged in" state, a visit counter all need something to survive across that gap anyway — and this chapter builds it exactly the way Chapter 5's own closing paragraph predicted: as ordinary middleware, reading a cookie before next_() and writing one after it returns.

Cookies: The Real Header on Both Sides

A cookie is nothing more than a header. The server sends Set-Cookie in a response; the browser sends it straight back as Cookie on every later request to the same site. Python's own standard library already parses and builds the real, correct syntax — http.cookies.SimpleCookie:

from http.cookies import SimpleCookie

c = SimpleCookie()
c['session_id'] = 'abc123'
c['session_id']['path'] = '/'
c['session_id']['max-age'] = 3600
c['session_id']['httponly'] = True
c['session_id']['samesite'] = 'Lax'
print(c['session_id'].OutputString())
# session_id=abc123; HttpOnly; Max-Age=3600; Path=/; SameSite=Lax

parser = SimpleCookie()
parser.load('session_id=abc123; theme=dark')
print({k: m.value for k, m in parser.items()})
# {'session_id': 'abc123', 'theme': 'dark'}

Wired into this chapter's own real Request and Response classes:

# added to Request (Chapter 3):
    @property
    def cookies(self):
        if self._cookies is None:
            jar = SimpleCookie()
            jar.load(self.environ.get('HTTP_COOKIE', ''))
            self._cookies = {k: m.value for k, m in jar.items()}
        return self._cookies

# added to Response (Chapter 3):
    def set_cookie(self, name, value, max_age=None, path='/', http_only=True, same_site='Lax'):
        cookie = SimpleCookie()
        cookie[name] = value
        cookie[name]['path'] = path
        if max_age is not None:
            cookie[name]['max-age'] = max_age
        if http_only:
            cookie[name]['httponly'] = True
        cookie[name]['samesite'] = same_site
        self.headers.append(('Set-Cookie', cookie[name].OutputString()))

A Real Session Store

Cookies alone can only carry text the client sends back verbatim — anything sensitive still needs to live on the server, keyed by an ID the cookie merely points at. A minimal in-memory store, with a genuine, per-session idle-timeout:

import secrets, time

class SessionStore:
    def __init__(self, max_age=3600):
        self._sessions = {}   # sid -> (data_dict, created_at)
        self.max_age = max_age

    def create(self):
        sid = secrets.token_urlsafe(32)
        self._sessions[sid] = ({}, time.time())
        return sid

    def load(self, sid):
        entry = self._sessions.get(sid)
        if entry is None:
            return None
        data, created_at = entry
        if time.time() - created_at > self.max_age:
            del self._sessions[sid]
            return None
        return data

    def save(self, sid, data):
        _, created_at = self._sessions.get(sid, ({}, time.time()))
        self._sessions[sid] = (data, created_at)

Wiring It in as Ordinary Middleware

No special-case machinery needed — the exact before-next_()/after-next_() shape Chapter 5 already built, reading the session cookie first and writing an updated one last:

def make_session_middleware(store, cookie_max_age=3600):
    def middleware(request, next_):
        sid = request.cookies.get('session_id')
        data = store.load(sid) if sid else None
        if data is None:
            sid = store.create()
            data = store.load(sid)
        request.state['session'] = data
        response = next_(request)
        store.save(sid, request.state['session'])
        response.set_cookie('session_id', sid, max_age=cookie_max_age)
        return response
    return middleware

def visit_counter_handler(request):
    session = request.state['session']
    session['visits'] = session.get('visits', 0) + 1
    return Response(f"You have visited {session['visits']} times")

store = SessionStore()
app = App()
app.use(make_session_middleware(store))
app.add_route('GET', '/', visit_counter_handler)

The Real Payoff: Why Sessions Need Cookies

Run the exact same code two genuinely different ways against a real live server:

# no cookie jar at all -- two plain, independent requests
urllib.request.urlopen('http://127.0.0.1:8891/').read()   # b'You have visited 1 times'
urllib.request.urlopen('http://127.0.0.1:8891/').read()   # b'You have visited 1 times'  -- still 1!

# a real cookie jar, mimicking an actual browser
jar = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(jar))
opener.open('http://127.0.0.1:8891/').read()   # b'You have visited 1 times'
opener.open('http://127.0.0.1:8891/').read()   # b'You have visited 2 times'
opener.open('http://127.0.0.1:8891/').read()   # b'You have visited 3 times'

Verified directly — identical server code, genuinely different real client behavior

Two plain urlopen() calls, with no jar, each receive their own real, distinct Set-Cookie header with a completely different session ID — and because nothing ever sends either cookie back, request.cookies.get('session_id') finds nothing on the second call, so make_session_middleware genuinely creates a brand-new session every single time. The count stays at 1 forever, not because of a bug, but because this client is never actually reusing anything. Switching to a real http.cookiejar.CookieJar — which automatically stores every real Set-Cookie it receives and resends it on every later request to the same host, exactly what a real browser does — makes the identical server-side code correctly count 1, 2, 3. The session was never really "in" the server alone; it only works because the cookie genuinely round-trips.

Server-Side Expiry Is a Genuinely Separate Control From the Cookie's Own Max-Age

A cookie's own Max-Age only governs when a well-behaved client stops sending it — nothing stops a client from ignoring that and resending an old cookie anyway. Real security has to come from the server checking independently, which is exactly what SessionStore.load()'s own timeout already does. Isolating that from the cookie's client-side lifetime means deliberately setting the two to genuinely different real values:

store = SessionStore(max_age=1)                                  # the SERVER's own 1-second idle-timeout
app.use(make_session_middleware(store, cookie_max_age=3600))  # the COOKIE's own much longer, 1-hour lifetime

Verified directly — the client still holds and still sends the exact same cookie; only the server rejects it

Real request 1 counts 1; real request 2, immediately after, counts 2. After sleeping 1.5 real seconds — past the server's own 1-second timeout, nowhere near the cookie's own 3600-second Max-Age — the jar was checked directly and confirmed still holding, and about to resend, the exact same session ID from request 1. The real third request nonetheless counts 1 again: a brand-new session, created because SessionStore.load() found the old one past its own real timeout and deleted it — entirely independent of whether the client ever intended to stop using that cookie.

Session ID Security: Unpredictability, and HttpOnly

A session ID that could be guessed would let an attacker impersonate another real user with zero access to their machine or cookies at all — which is exactly why secrets.token_urlsafe(), not random or a counter, generates them:

ids = set()
for _ in range(20000):
    ids.add(secrets.token_urlsafe(32))
print(len(ids))
# 20000  -- zero collisions

Verified directly — 20,000 real, independently generated IDs, zero collisions

secrets.token_urlsafe(32) draws from Python's own real, documented cryptographically-secure random source, producing a 43-character real string with 256 bits of genuine entropy — 20,000 real calls in a row produced 20,000 real, distinct values.

set_cookie()'s own default of http_only=True ties directly back to Chapter 4's own real, verified XSS vulnerability — unescaped output there let a genuine <script> tag execute in the page. Without HttpOnly, that same script could read document.cookie and steal a real session ID outright:

r_on = Response(); r_on.set_cookie('session_id', 'abc', http_only=True)
print(dict(r_on.headers)['Set-Cookie'])
# session_id=abc; HttpOnly; Path=/; SameSite=Lax

r_off = Response(); r_off.set_cookie('session_id', 'abc', http_only=False)
print(dict(r_off.headers)['Set-Cookie'])
# session_id=abc; Path=/; SameSite=Lax   -- no HttpOnly at all

Verified directly — the flag's real presence or absence on the actual header

A browser genuinely honoring HttpOnly refuses to expose a cookie carrying it to any JavaScript running on the page at all — including a script Chapter 4's own real XSS vulnerability might have injected. Without the flag, that identical injected script has a real, working path straight to a live session ID. Defaulting http_only=True means a developer has to deliberately opt out to create that exposure, not deliberately opt in to close it.

Where This Course Is Headed

Chapter 7 builds a minimal ORM — mapping real Python objects to real SQL — giving SessionStore an honest, real alternative to its own current in-memory dict, one that survives an actual server restart.

Hands-On Exercises

Exercise 1

Add a real Response.delete_cookie(name) method (a Set-Cookie with Max-Age=0) and a /logout route that calls it, register both on a real App with the session middleware, and verify with a real cookie jar that a request made right after logout starts a brand-new session (the visit counter resets to 1) rather than reusing the old one.

📄 View solution

Exercise 2

Build two real Response objects, one with set_cookie(..., http_only=True) and one with http_only=False, and verify directly on each one's own real Set-Cookie header string that HttpOnly is present in exactly one of the two — then explain in your own words, tying back to Chapter 4's own real XSS finding, what a real attacker's injected script could and couldn't do differently between the two cases.

📄 View solution

Exercise 3

Using this chapter's own visit_counter_handler and session middleware, create two separate, independent http.cookiejar.CookieJar-backed openers (simulating two different real browsers) against the same running App, interleave real requests from both, and verify each one's own visit count increments completely independently of the other.

📄 View solution

Chapter 6 Quick Reference

Cookies — a plain header pair, Set-Cookie/Cookie, real-parsed and real-built via http.cookies.SimpleCookie
Request.cookies / Response.set_cookie() — lazy-parsed cookie access, and a header-building helper defaulting to HttpOnly
SessionStore — a real in-memory dict of sid -> (data, created_at), with a genuine per-session idle-timeout on load()
Session middleware — the exact before-next_()/after-next_() shape from Chapter 5: load or create before, save and set the cookie after
Why sessions need cookies — verified live: no cookie jar means a brand-new session every request (stuck at 1); a real jar makes the identical code count 1, 2, 3
Server-side expiry is independent — verified live: the client still holds and sends the same unexpired-by-Max-Age cookie; only the server's own timeout invalidates it
Session ID security — secrets.token_urlsafe(32), verified with zero collisions across 20,000 real IDs; HttpOnly defaults on, closing the exact cookie-theft path Chapter 4's own real XSS finding opened
Next chapter: A minimal ORM — mapping real Python objects to real SQL