Exercices corrigés Node.js et Express type E6 et E7

1. 401, {"erreur":"Clé absente"} : le middleware répond avant la route.
2. 200, [{"id":2,"libelle":"Vidéoprojecteur","etat":"prete"}].
3. 404, {"erreur":"Introuvable"} : req.params.id vaut la chaîne "1", et 1 === "1" est faux. Aucun matériel n'est jamais trouvé.
4. 200, [] : la comparaison respecte la casse, aucun matériel n'a l'état PRETE.

Correction : materiels.find((m) => m.id === Number(req.params.id)), ou mieux, valider le paramètre avec Zod (z.coerce.number().int().positive()) et refuser abc avec 422.

Le contrôle de clé vérifie seulement la présence de l'en-tête : n'importe quelle valeur passe. Il faut comparer la clé à une valeur secrète (stockée hachée, comme un mot de passe), ou utiliser une vraie authentification par jeton.

1. journalRequetes (src/logger.js) : identifiant de requête, journal.
2. helmet(), cors(…), express.json() (src/app.js) : en-têtes, CORS, lecture du corps.
3. Le routeur des fiches, branché sur /v1/fiches (src/routes/fiches.routes.js) : authentifier (src/middlewares/authentifier.js) vérifie le jeton et remplit req.utilisateur ; exigerRole('visiteur') (src/middlewares/autoriser.js) ; valider({ params: schemaId, body: schemaLignesForfait }) (src/middlewares/valider.js) remplit req.valide.
4. Le contrôleur saisirForfait (src/controllers/fiches.controller.js) appelle le service.
5. Le service saisirForfait (src/services/fiches.service.js) : chargerFiche vérifie l'existence et le propriétaire, exigerEnCours vérifie l'état CR.
6. Le dépôt enregistrerQuantites (src/depots/fiches.depot.js) : quatre UPDATE dans une transaction.
7. Le service relit la fiche (lireFiche) et calcule le total ; le contrôleur répond 200 avec la fiche.

Nouveau total : 4 × 110 + 420 × 0,62 + 2 × 80 + 6 × 25 + 23,50 = 440 + 260,40 + 160 + 150 + 23,50 = 1 033,90 €.

// src/depots/fiches.depot.js
export async function compterParEtat(mois) {
  const [lignes] = await pool.execute(
    'SELECT etat, COUNT(*) AS nombre FROM fiche_frais WHERE mois = ? GROUP BY etat ORDER BY etat',
    [mois],
  );
  return lignes;
}

// src/schemas/fiches.schemas.js
export const schemaStats = z.object({ mois });

// src/routes/stats.routes.js, branché avec app.use('/v1/stats', routeurStats)
export const routeurStats = Router();
routeurStats.get('/', authentifier, exigerRole('comptable'), valider({ query: schemaStats }), async (req, res) => {
  res.json(await depot.compterParEtat(req.valide.query.mois));
});

Réponse pour octobre 2026 : [{"etat":"CR","nombre":1},{"etat":"CL","nombre":1}] (la fiche 12 de Lucas en cours, la 13 de Sarah clôturée). Avec MySQL, ORDER BY etat sur une colonne ENUM trie dans l'ordre de déclaration (CR, CL, VA, MP), pas dans l'ordre alphabétique : c'est justement l'ordre du cycle de vie. Pour une route aussi simple, le service est facultatif ; s'il y a une règle (masquer les mois futurs, par exemple), elle va dans un service.

SELECT f.id, u.nom, u.prenom, f.etat,
       (SELECT COALESCE(SUM(l.quantite * ff.montant), 0)
          FROM ligne_frais_forfait l JOIN frais_forfait ff ON ff.code = l.code_forfait
         WHERE l.id_fiche = f.id)
     + (SELECT COALESCE(SUM(h.montant), 0) FROM frais_hors_forfait h WHERE h.id_fiche = f.id) AS total
  FROM fiche_frais f
  JOIN utilisateur u ON u.id = f.id_visiteur
 WHERE f.mois = ?
 ORDER BY u.nom

Deux sous-requêtes corrélées plutôt que deux jointures : joindre en même temps les lignes de forfait (4 par fiche) et les frais hors forfait multiplierait les lignes, et les sommes seraient fausses (chaque frais hors forfait compté 4 fois). Le calcul se fait en DECIMAL, exact. Avec decimalNumbers: true, mysql2 renvoie 898.9 et 567.

1. Base : ALTER TABLE fiche_frais ADD COLUMN commentaire VARCHAR(255) NULL; (dans un script de migration numéroté, versionné).
2. Validation : schemaValidation devient z.strictObject({ montantValide: …, commentaire: z.string().trim().max(255).optional() }).
3. Dépôt : changerEtat accepte le commentaire et l'écrit (SET etat = ?, montant_valide = COALESCE(?, montant_valide), commentaire = COALESCE(?, commentaire)), avec null par défaut ; versFiche et le SELECT exposent commentaire.
4. Service et contrôleur : validerFiche(utilisateur, id, montantValide, commentaire) transmet la valeur ; le contrôleur lit req.valide.body.commentaire.
5. Documentation : le schéma de la requête de validation dans openapi.yaml.

it('enregistre le commentaire de validation', async () => {
  const reponse = await request(app)
    .post('/v1/fiches/13/validations')
    .set('Authorization', await jetonDe('adurand', 'Comptable#2026'))
    .send({ montantValide: 555, commentaire: 'Parking refusé : sans justificatif' });
  assert.equal(reponse.status, 201);
  assert.equal(reponse.body.commentaire, 'Parking refusé : sans justificatif');
});

Pense aussi au test du refus : un commentaire de 300 caractères doit donner 422.

!quantite est vrai pour 0 : la quantité zéro est ignorée, et l'ancienne valeur reste. Le test « champ vide » est inutile, puisque le schéma Zod exige déjà les quatre quantités, entières et positives ou nulles. Correction : supprimer la ligne if, et en profiter pour regrouper les quatre mises à jour dans une transaction (version du chapitre 6).

it('enregistre une quantité nulle', async () => {
  const jeton = await jetonDe('lmartin', 'Visiteur#2026');
  const reponse = await request(app)
    .put('/v1/fiches/12/lignes-forfait')
    .set('Authorization', jeton)
    .send({ ETP: 3, KM: 420, NUI: 2, REP: 0 });
  assert.equal(reponse.status, 200);
  assert.equal(reponse.body.lignesForfait.find((l) => l.code === 'REP').quantite, 0);
});

Le cas limite (zéro, chaîne vide, liste vide) est l'endroit où se cachent les bogues : c'est le premier à tester.

1. Jeton non vérifié (jwt.decode) : decode lit la charge utile sans vérifier la signature. N'importe qui fabrique un jeton qui dit "role": "comptable". Correction : jwt.verify(jeton, secret, { algorithms: ['HS256'] }), et un 401 si le jeton est absent ou invalide (API2, authentification défaillante).
2. Pas d'authentification obligatoire : sans jeton, req.utilisateur vaut null et les routes s'exécutent quand même. Correction : le middleware authentifier sur toutes les routes protégées.
3. BOLA sur GET /v1/fiches/:id : aucune vérification du propriétaire ; tout le monde lit toutes les fiches en changeant l'identifiant. Correction : contrôle du propriétaire dans le service, 404 sinon (API1).
4. Exposition de données : SELECT * renvoie toutes les colonnes ; et une fiche absente renvoie 200 avec un corps vide au lieu de 404 (API3).
5. Affectation de masse sur PATCH : avec SET ?, mysql2 transforme tout l'objet req.body en colonnes à modifier. Un visiteur envoie {"etat":"VA","montant_valide":5000} et valide lui-même sa fiche. Pas de contrôle de rôle ni de transition non plus. Correction : schéma Zod strict ({ etat: z.enum(['CL','MP']) }), contrôle du rôle et de la transition dans le service, requête écrite colonne par colonne (API3 et API5).
6. Fuite d'informations dans le gestionnaire d'erreurs : message, requête SQL et pile d'appels renvoyés au client. Correction : message générique, numéro d'incident, détail dans le journal (API8).

Et la configuration CORS (origin: true, credentials: true) autorise n'importe quel site à lire les réponses avec les cookies de l'utilisateur : liste blanche des origines (API8).

1. Une attaque par force brute (ou par dictionnaire) sur le compte adurand, la comptable : dix échecs en deux secondes depuis la même adresse, puis 429. La limitation de débit de la route de connexion a bloqué la suite. Le message unique et le temps de réponse identique empêchent en plus de savoir si le login existe.
2. L'utilisateur 7 (Lucas, ou quelqu'un qui a volé son jeton) parcourt les identifiants de fiches un par un : c'est une tentative d'exploitation d'un BOLA. L'API a bien réagi : 404 pour toutes les fiches qui ne sont pas les siennes, aucune donnée n'a fuité.
3. Détecter : une alerte quand un même utilisateur accumule des 404 sur des ressources existantes, ou quand une adresse cumule les 429. Réagir : contacter Lucas, révoquer ses jetons et lui faire changer son mot de passe si le jeton a été volé ; bloquer temporairement l'adresse 203.0.113.24. Renforcer : limitation de débit par utilisateur sur les routes authentifiées, double authentification pour les comptables, conservation de ces journaux pour l'enquête.

routeurVehicules.use(authentifier);
routeurVehicules.get('/', vehicules.lister);                                        // tous les rôles
routeurVehicules.post('/', exigerRole('flotte'), valider({ body: schemaVehicule }), vehicules.ajouter);
routeurReservations.use(authentifier);
routeurReservations.post('/', exigerRole('visiteur', 'flotte'), valider({ body: schemaReservation }), reservations.creer);
routeurReservations.delete('/:id', exigerRole('visiteur', 'flotte'), valider({ params: schemaId }), reservations.annuler);

// service : le rôle ne suffit pas, il faut aussi le propriétaire
export async function annulerReservation(utilisateur, id) {
  const reservation = await depot.trouverParId(id);
  const autorise = reservation && (utilisateur.role === 'flotte' || reservation.utilisateurId === utilisateur.id);
  if (!autorise) throw new ErreurApi(404, 'reservation-introuvable', 'Réservation introuvable', `La réservation ${id} n'existe pas.`);
  await depot.supprimer(id);
}

Le rôle flotte s'ajoute à l'énumération de la colonne role de la table utilisateur (ALTER TABLE utilisateur MODIFY role ENUM('visiteur','comptable','flotte') NOT NULL DEFAULT 'visiteur') et au type Role si l'on utilise Prisma. Les lignes « annuler sa réservation » et « annuler n'importe laquelle » ne peuvent pas être traduites par exigerRole seul : elles demandent un contrôle sur la donnée, dans le service.