Nour se connecte à l'espace numérique du lycée

(a) le navigateur envoie GET /accueil, avec l'en-tete Cookie: session=8f3a
(b) le serveur repond 302 et Set-Cookie: session=8f3a
(c) Nour remplit le formulaire et clique
(d) le serveur retrouve la session 8f3a, lit le prenom en base, fabrique le HTML
(e) le navigateur enregistre le cookie
(f) le serveur compare l'empreinte du mot de passe a celle qui est en base
(g) le navigateur affiche « Bonjour Nour »
(h) le navigateur envoie POST /connexion avec pseudo et motdepasse

1.

Deux requêtes, donc deux allers-retours : la connexion, puis l'accueil. C'est la redirection 302 de l'étape 4 qui déclenche la seconde — le navigateur obéit sans que Nour ait rien cliqué. Notez que l'étape 6 renvoie le cookie automatiquement : aucune ligne de JavaScript n'a été écrite pour cela.

2. Parce qu'un cookie est rangé chez le client, donc modifiable par lui. Si le serveur lisait le prénom dans le cookie, il suffirait de le changer pour se faire appeler autrement — ce qui est anodin. Mais le même raisonnement vaut pour un cookie qui porterait eleve=nour ou role=professeur : on se donnerait alors des droits en modifiant une chaîne de caractères dans son propre navigateur.

D'où la règle : le cookie de session ne contient qu'un identifiant opaque et imprévisible. Il ne dit rien ; il ne fait que désigner une session dont tout le contenu — qui vous êtes, ce que vous avez le droit de voir — reste sur le serveur.

Prolongement : c'est la même idée qu'à l'exercice précédent, appliquée à l'identité au lieu du prix. Ce que le client détient, le client peut le changer ; le serveur ne doit donc lui confier qu'une clé, jamais la réponse.