Make it yours.

1. Look at the cookie in the browser. Register, then open DevTools → Application → Cookies. Find signflow_session: HttpOnly is checked (so document.cookie in the console won't show it — try it), SameSite is Lax. This is the token; the server holds only its hash.

2. Prove the hash-at-rest claim. The cookie value and the token_hash column are different strings. Copy the cookie value, then SELECT token_hash FROM sessions; — they don't match, because the stored one is SHA-256(cookie value). A stolen database backup contains no usable sessions.

3. Hit every guardrail. Register the same email twice → "already registered". Submit mismatched passwords → "do not match". Try a 3-character password → the length error. Each is a branch in Register; find the line that produced each message.

4. Delete a session by hand. DELETE FROM sessions;, then reload. Nothing visibly changes yet — because nothing reads the session cookie into "you're logged in" until next lesson. But you've just done, by hand, exactly what logout will do in one query.

Where this is going. You can register and you have a live session — but the app doesn't act on it: there's no "logged in" header, no protected page, no way to log in again or out. Lesson 5 adds the two pieces of middleware that make sessions real: LoadUser (resolve the cookie into the current user on every request) and RequireAuth (guard pages that need a login). Plus login, logout — one DELETE, the thing a JWT can't do — and the account-enumeration defences that keep an attacker from discovering which emails are registered.