Unit 7 · Data that lasts
How a site knows you’re logged in
After you log in, the server issues a session token and your browser sends it with each request. The server checks the token it issued; it never trusts a name the page claims, and it does not need your password again.
The mix-up
What people often think
“Sending the password every time is the most secure way to prove who you are.”
What the tutor says
Every extra trip is another chance for the password to leak, and the browser would have to store it. A session token can be cancelled; a leaked password works everywhere she reused it.
How it works
Sending the password on every request means storing it in the browser and giving it more chances to leak. A token can be cancelled; a leaked password works everywhere someone reused it.
Anything in the browser can be edited. If the server believed localStorage saying “user: Ana”, anyone could change it to “admin”.
Close cousins of this mix-up
The tutor watches for these in the same lesson.
“The server can trust what the page says about who is logged in.”
Anyone can edit localStorage and type "user: Ana". The server must check a token it issued itself, not a name the browser claims.
Practise it with a tutor watching
APIs and auth basics
Keep secret keys on the server and explain how a site knows who you are after you log in.
Free with an account. The first two units need no account.