# Récapitulatif de l'authentification

## Objectif
L'authentification du backend sert à protéger les routes API sensibles et à permettre une connexion simple depuis le web ou depuis un outil de test.

## Principe général
Le backend utilise un JWT. Après un login réussi, il renvoie le token dans la réponse JSON et le stocke aussi dans un cookie `HttpOnly` nommé `auth_token`.

Cela permet deux façons d'appeler les routes protégées :
- par l'en-tête `Authorization: Bearer <token>`
- par le cookie `auth_token` envoyé automatiquement par le navigateur

## Login
La route `POST /api/auth/login` :
- valide le JSON reçu
- vérifie les identifiants admin via les variables d'environnement
- génère un JWT
- renvoie le token dans le JSON
- définit aussi le cookie `auth_token`

## Vérification du token
La route `GET /api/auth/me` :
- lit le cookie `auth_token` si présent
- sinon lit l'en-tête `Authorization`
- vérifie le JWT
- renvoie l'utilisateur si le token est valide

## Protection des routes
Un helper partagé `requireAuth` vérifie la présence et la validité du token.

Il est utilisé sur les routes sensibles, notamment :
- `GET/POST /api/employes`
- `GET/PUT/DELETE /api/employes/[cos]`
- `GET /api/employes/[cos]/sanctions`
- `GET /api/employes/[cos]/disciplinaires`
- `GET/POST /api/contrats`
- `GET/PUT/DELETE /api/contrats/[id]`
- `GET /api/contrats/[id]/avenants`
- `GET/POST /api/avenants`
- `GET/POST /api/absences`
- `GET/PUT/DELETE /api/absences/[id]`
- `GET/POST /api/diplomes`
- `GET/PUT/DELETE /api/diplomes/[id]`
- `GET/POST /api/visites-medicales`
- `GET/PUT/DELETE /api/visites-medicales/[id]`

## CORS et cookies
Le middleware gère aussi les réponses `OPTIONS` et ajoute les en-têtes CORS nécessaires.

En développement, l'origine autorisée est :
- `http://localhost:3000`

Le backend ajoute :
- `Access-Control-Allow-Origin`
- `Access-Control-Allow-Headers`
- `Access-Control-Allow-Credentials`

## Cookie en développement
En local, le cookie est configuré avec :
- `HttpOnly`
- `SameSite=Lax`
- `Path=/`
- expiration de 24 heures

En production, il passe en :
- `HttpOnly`
- `SameSite=None`
- `Secure=true`

## Comment tester
### Avec le navigateur
Ouvre :
- `http://localhost:3000/test-cookie.html`

Étapes :
1. cliquer sur `Se connecter`
2. cliquer sur `Tester /api/auth/me`
3. cliquer sur une route protégée, par exemple `GET /api/employes/1937`

### Avec Hoppscotch
- active l'auth
- choisis `Bearer`
- colle le token dans le champ prévu
- ou laisse le navigateur envoyer le cookie si tu utilises `credentials: include`

### Avec le script PowerShell
Le script de test se trouve ici :
- `scripts/test-auth.ps1`

Il teste :
- `POST /api/auth/login`
- `GET /api/auth/me`
- une route protégée optionnelle

## Points importants
- `document.cookie` ne peut pas lire un cookie `HttpOnly`
- le bon test de session est `GET /api/auth/me`
- si une route renvoie `401`, le token manque ou n'est pas valide
- si le navigateur bloque la requête, regarder les erreurs CORS dans la console

## Fichiers clés
- `backend/backend_envie2e/src/app/api/auth/login/route.ts`
- `backend/backend_envie2e/src/app/api/auth/me/route.ts`
- `backend/backend_envie2e/src/lib/jwt.ts`
- `backend/backend_envie2e/src/lib/requireAuth.ts`
- `backend/backend_envie2e/middleware.ts`
- `backend/backend_envie2e/public/test-cookie.html`