La collection utilisateurs
Un Utilisateur a un email, un mot de passe haché (jamais en clair !) et des rôles.
@Document("utilisateurs") public class Utilisateur { @Id String id; @Indexed(unique=true) String email; String motDePasseHash; List<String> roles; // [PARTICULIER] ou [COORDINATEUR] }
Hachage — on stocke
passwordEncoder.encode(motDePasse) (BCrypt). On ne peut jamais retrouver le mot de passe d'origine.Inscription & connexion
Deux endpoints publics : register crée l'utilisateur (mot de passe haché) ; login vérifie les identifiants et renvoie un JWT.
POST /api/auth/register { email, motDePasse, role }
POST /api/auth/login { email, motDePasse } → { token }
Protéger les endpoints
On applique les règles du chapitre 12 au projet :
GET /api/campagnes/**→ public.POST /api/campagnes,PUT .../cloturer→COORDINATEUR.POST .../commandes→ tout utilisateur authentifié.
Durcir (lien Cyber)
- Mots de passe hachés (BCrypt), jamais journalisés.
- JWT à expiration courte ; secret de signature en variable d'environnement.
- Validation des entrées (chapitre 5) contre les injections.
- HTTPS en production (chapitre 14).
🛢️ Sur le projet Fioul Groupé
Implémente register/login, protège les endpoints par rôle, teste avec Swagger (bouton « Authorize » pour coller le JWT). Rédige une courte analyse de risques à joindre au dossier — passerelle directe avec ton cours de cybersécurité.
À retenir
- Mots de passe hachés (BCrypt) ; email unique.
loginémet un JWT ; endpoints protégés par rôle.- Durcissement : expiration, secret en env, validation, HTTPS.