Interagir sur le Web

<form id="connexion" method="post" action="/verifier">
  <label for="pseudo">Pseudonyme</label>
  <input type="text" id="pseudo" name="pseudo">

  <label for="motdepasse">Mot de passe</label>
  <input type="password" id="motdepasse" name="motdepasse">

  <input type="checkbox" id="memoriser" name="memoriser">
  <label for="memoriser">Se souvenir de moi</label>

  <button type="submit">Se connecter</button>
</form>

Les composants graphiques sont ici les champs de saisie, la case à cocher et le bouton. Chacun porte un name — le nom sous lequel sa valeur sera transmise — et souvent un id, qui permet au code de le désigner.

10.2 Les événements

Le renversement est complet par rapport à tout ce qui précède : le programme n'appelle plus, il est appelé.

Figure : Le modèle événementiel. Le gestionnaire est écrit à l'avance et attend ; c'est le navigateur qui décide du moment où il s'exécute.

// Le comportement : ce que fait la page quand on clique.
const bouton = document.getElementById("compter");
const affichage = document.getElementById("total");
let compteur = 0;

bouton.addEventListener("click", function () {
    compteur = compteur + 1;
    affichage.textContent = compteur;
});

10.3 Client et serveur

1. Vous tapez une adresse.
2. Le navigateur demande au DNS l'adresse IP correspondant au nom.
3. Le CLIENT envoie une requete HTTP :        GET /connexion HTTP/1.1
4. Le SERVEUR l'execute, puis repond :        200 OK  + le code HTML
5. Le CLIENT interprete le HTML, applique le CSS,
   telecharge et execute le JavaScript.
6. La page attend. Chaque clic execute du code SUR LE CLIENT.
7. A l'envoi du formulaire, le CLIENT renvoie une requete au SERVEUR,
   qui l'execute a son tour.

Figure : Un échange complet. Entre la deuxième et la troisième flèche, le serveur ne sait rien de

ce qui se passe : la page vit seule, dans le navigateur.</div>

ImportantLa question à se poser devant tout traitement : où s'exécute-t-il ?

Sur le client	Sur le serveur
afficher, masquer, animer	consulter une base de données
vérifier la forme d'une saisie	vérifier un mot de passe
calculer un total affiché	enregistrer une commande
réagir à un clic	décider ce que l'utilisateur a le droit de voir

Le partage n'est pas une question de commodité, mais de confiance : tout ce qui s'exécute sur le client peut être lu, modifié ou contourné par l'utilisateur. Une vérification faite uniquement côté client est un confort, jamais une sécurité.

AttentionUn exemple qui a coûté cher à beaucoup de sites

Vérifier en JavaScript qu'un mot de passe fait au moins huit caractères est utile : cela évite un aller-retour et prévient l'utilisateur tout de suite. Mais rien n'empêche d'envoyer la requête sans passer par la page — le serveur doit refaire la vérification.

La règle tient en une phrase : le serveur ne fait jamais confiance à ce que le client lui envoie.

10.4 Les formulaires : GET ou POST

Capacité attendue

« Analyser le fonctionnement d'un formulaire simple. Distinguer les transmissions de paramètres par les requêtes POST ou GET. »

	GET	POST
Où vont les paramètres	dans l'URL, après `?`	dans le corps de la requête
Visibles dans la barre d'adresse	oui	non
Conservés dans l'historique	oui	non
Peut-on placer l'URL en favori	oui	non
Taille	limitée	non limitée en pratique
Usage	consulter, rechercher	envoyer, modifier, payer

GET  /recherche?ville=Nantes&jours=5 HTTP/1.1
Host: exemple.fr

POST /verifier HTTP/1.1
Host: exemple.fr
Content-Type: application/x-www-form-urlencoded

pseudo=nour&motdepasse=secret

Figure : Où voyagent les paramètres. POST les retire de la barre d'adresse, rien de plus : sur le

réseau, ils circulent aussi lisiblement qu'en GET tant que la connexion n'est pas en HTTPS.</div>

Méthode : Lequel choisir ?

Le programme demande de « discuter les deux types de requêtes selon le type des valeurs à transmettre et/ou leur confidentialité » :

• la requête ne change rien et son résultat peut être partagé — une recherche, un filtre, une page de catalogue : GET. L'URL devient partageable, et c'est un avantage.
• la requête modifie quelque chose, ou transporte une valeur confidentielle — connexion, achat, publication : POST.

AttentionPOST ne chiffre rien

C'est le contresens le plus répandu du chapitre. Une requête POST cache seulement les paramètres de la barre d'adresse : ils circulent sur le réseau exactement aussi lisiblement qu'en GET.

Ce qui chiffre, c'est HTTPS — le s de l'adresse et le cadenas du navigateur. Sans lui, un mot de passe envoyé en POST traverse le réseau en clair et peut être lu par n'importe quel intermédiaire.

Capacité attendue

« Reconnaître quand et pourquoi la transmission est chiffrée. »

ImportantCe que HTTPS protège, et ce qu'il ne protège pas

Il protège le contenu échangé — nul intermédiaire ne lit ni ne modifie ce qui passe — et il atteste que le serveur est bien celui qu'il prétend être, au moyen d'un certificat.

Il ne protège pas de ce que fait le site lui-même. Un site malveillant en HTTPS reste malveillant : le cadenas dit « personne d'autre n'écoute », pas « ce site est honnête ». La nuance mérite d'être sue.

10.5 Ce que le client garde en mémoire

Set-Cookie: session=8f3a91b2; Secure; HttpOnly

Un cookie est une petite donnée que le serveur demande au client de conserver et de lui retransmettre à chaque requête suivante. C'est ce qui permet à un site de vous reconnaître d'une page à l'autre, alors que HTTP, lui, ne garde aucun souvenir d'une requête à la suivante.

iRemarque

Le mécanisme est neutre ; ses usages ne le sont pas. Le même dispositif sert à maintenir une session ouverte — utile — et à suivre un internaute de site en site pour établir son profil publicitaire. C'est ce que le programme range parmi les compétences transversales : « faire un usage responsable et critique de l'informatique ».

Repère historique : 1989-1993 : trois inventions en une

En 1989, au CERN, Tim Berners-Lee propose un système de documents reliés entre eux pour organiser l'information des équipes de physiciens. Il en écrit les trois pièces : le langage de description HTML, le protocole de dialogue HTTP, et l'adresse universelle URL.

Le geste décisif vient en 1993 : le CERN place la technologie dans le domaine public, gratuitement et sans restriction. Le Web n'appartient à personne — c'est cette décision, autant que l'invention, qui explique ce qu'il est devenu.

Piste de projet : Une page qui réagit

Réaliser une petite application Web entièrement côté client : convertisseur d'unités, quiz, minuteur, ou le visualiseur de bases du chapitre 1. Cahier des charges minimal : au moins deux composants graphiques, deux événements différents, une vérification de la saisie, et un affichage qui se met à jour sans recharger la page.

Le compte rendu doit répondre à une question précise : qu'est-ce qui, dans votre application, devrait passer par un serveur si elle était mise en ligne pour de vrai, et pourquoi ?

Continuer sur Adloun : animation, QCM, fiches, exercices