AdamThomasandClaude Sonnet 5
89e74e5ec7
Audit de l'application avant sa première publication sur internet. Correctifs immédiats, peu coûteux et sans changement de comportement en dev : - Le backend refuse de démarrer en `ENVIRONMENT=production` si `JWT_SECRET` est vide, trop court ou égal à la valeur par défaut versionnée dans `.env.example` — sinon n'importe qui pourrait forger un jeton de session valide (y compris pour un compte COORDINATION) sans jamais s'authentifier. Testé (`test_config.py`). - Avertissement au démarrage si `EMAIL_ENABLED=false` en production : dans ce cas le jeton de lien magique est journalisé en clair (confort de dev, cf. `api/auth.py`) — un identifiant de connexion en clair dans les logs du conteneur en public serait un vrai problème. - `frontend/nginx.conf` : plus de journal d'accès (la route `/connexion?token=…` y ferait apparaître le jeton de lien magique en clair), en-têtes `X-Content-Type-Options`, `X-Frame-Options`, `Referrer-Policy` (empêche aussi la fuite de ce même jeton vers Google Fonts via l'en-tête Referer), `server_tokens off`. - `deploy/Caddyfile.benevoles` : mêmes en-têtes côté reverse proxy public, plus `Strict-Transport-Security`. - `deploy/README.md` : check-list sécurité avant ouverture (secret, SMTP, ne jamais mettre en production la base de démo `app.seed` — le mot de passe du compte coordination y est versionné en clair —, limites connues comme l'absence de rate-limiting sur `/auth/*`). Points vérifiés sans modification nécessaire : autorisation par rôle et cloisonnement par édition cohérents sur tous les endpoints (`owned_or_404` + vérification d'édition partout), mots de passe bcryptés, jetons de lien magique à usage unique haché en base (256 bits d'entropie), pas de PII/jeton dans les logs applicatifs (RGPD déjà en place), pas d'injection de gabarit dans les emails (substitution sur liste blanche, pas de `.format()`), pas d'injection d'en-tête SMTP (`EmailMessage` du socle Python), pas de `dangerouslySetInnerHTML` côté front, jeton JWT en `Authorization: Bearer` (pas de cookie ⇒ pas de CSRF), `.env` jamais versionné, dépendances à jour. Restent des choix à trancher avec l'utilisateur plutôt qu'à décider seul (compromis effort/risque) : rate-limiting sur les endpoints d'authentification, désactivation de `/docs` en production, conteneurs non-root. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017uUsRg7XzopkCPWimwg9ZM
Gestion des bénévoles
Application web de gestion des bénévoles pour un festival associatif. Backend FastAPI + PostgreSQL, frontend React (à venir), déploiement Docker Compose auto-hébergé.
Voir CLAUDE.md pour le vocabulaire du domaine, l'arborescence
et les conventions.
Démarrage rapide
make demo # base + backend + frontend, jeu de démonstration chargé
make blank # idem, mais édition vierge + 1er compte coordination
- Frontend : http://localhost:5173
- API : http://localhost:8000 · Docs : http://localhost:8000/docs
make downarrête tout ·make logssuit les logs du backend
Chaque commande construit les images, applique les migrations, prépare les
données, bascule le frontend sur l'API réelle (.env) et affiche les
identifiants de connexion.
make blank accepte des paramètres :
make blank EMAIL=moi@festival.fr PASSWORD=mon-mot-de-passe-solide \
NAME="Festival 2026" START=2026-07-01 END=2026-07-04
Le jeu de démo : 120 bénévoles fictifs, 15 postes, 4 jours. L'édition vierge : une édition + un compte coordination (mot de passe) + 3 créneaux types.
Tests
docker compose run --rm backend uv run pytest
La base de test (benevoles_test) est créée automatiquement au premier
démarrage du conteneur PostgreSQL.
Structure
| Dossier | Rôle |
|---|---|
backend/ |
API FastAPI, modèle SQLModel, migrations Alembic |
frontend/ |
Interface React + Vite + TS + Tailwind (service frontend) |
deploy/ |
Configuration de déploiement production (compose, Caddy, runbook) |
.gitlab-ci.yml |
Chaîne CI/CD (tests → build → SSH sur le VPS) |