37c62206ad
Résolution des incohérences #10, #11, et #12 de l'analyse d'architecture. ## Phase 1 : Réorganisation Features BDD (Point #10 - RÉSOLU) - Créer structure features/{api,ui,e2e} - Déplacer 83 features en 3 catégories via git mv (historique préservé) - features/api/ : 53 features (tests API backend) - features/ui/ : 22 features (tests UI mobile) - features/e2e/ : 8 features (tests end-to-end) Domaines déplacés : - API : authentication, recommendation, rgpd-compliance, content-creation, moderation, monetisation, premium, radio-live, publicites - UI : audio-guides, navigation, interest-gauges, mode-offline, partage, profil, recherche - E2E : abonnements, error-handling ## Phase 2 : Mise à jour Documentation ### ADR-007 - Tests BDD - Ajouter section "Convention de Catégorisation des Features" - Documenter règles api/ui/e2e avec exemples concrets - Spécifier step definitions (backend Go, mobile Dart) ### ADR-024 - Stratégie CI/CD Monorepo (NOUVEAU) - Créer ADR dédié pour stratégie CI/CD avec path filters - Architecture workflows séparés (backend.yml, mobile.yml, shared.yml) - Configuration path filters détaillée avec exemples YAML - Matrice de déclenchement et optimisations (~70% gain temps CI) - Plan d'implémentation (~2h, reporté jusqu'au développement) ### ADR-016 - Organisation Monorepo - Simplifier en retirant section CI/CD détaillée - Ajouter référence vers ADR-024 pour stratégie CI/CD ### INCONSISTENCIES-ANALYSIS.md - Point #10 (Tests BDD synchronisés) : ✅ RÉSOLU - Catégorisation features implémentée - ADR-007 mis à jour avec convention complète - Point #11 (70/30 Split paiements) : ✅ ANNULÉ (faux problème) - ADR-009 et Règle 18 parfaitement cohérents - Documentation exhaustive existante (formule, SQL, comparaisons) - Point #12 (Monorepo path filters) : ⏸️ DOCUMENTÉ - Architecture CI/CD complète dans ADR-024 - Implémentation reportée (projet en phase documentation) - Métriques mises à jour : - MODERATE : 6/9 traités (4 résolus + 1 annulé + 1 documenté) - ADR à jour : 100% (19/19 avec ADR-024) ## Phase 3 : Validation - Structure features validée (api/ui/e2e, aucun répertoire restant) - Historique Git préservé (git mv, renommages détectés) - 83 features total (API: 53, UI: 22, E2E: 8) Closes: Point #10 (résolu), Point #11 (annulé), Point #12 (documenté) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
115 lines
5.1 KiB
Gherkin
115 lines
5.1 KiB
Gherkin
# language: fr
|
|
Fonctionnalité: Gestion des sessions et tokens
|
|
En tant qu'utilisateur connecté
|
|
Je veux que mes sessions soient sécurisées et gérées automatiquement
|
|
Afin de maintenir l'accès à l'application sans friction
|
|
|
|
Contexte:
|
|
Étant donné que l'API RoadWave est disponible
|
|
Et que je suis connecté avec succès
|
|
|
|
Scénario: Access token expire après 15 minutes
|
|
Étant donné que j'ai reçu un access token
|
|
Et que 15 minutes se sont écoulées
|
|
Quand je fais une requête API avec cet access token
|
|
Alors la requête échoue avec le code 401
|
|
Et je vois le message "Token expiré"
|
|
|
|
Scénario: Refresh automatique du token avec refresh token
|
|
Étant donné que mon access token a expiré
|
|
Et que mon refresh token est valide
|
|
Quand l'application demande un nouveau access token
|
|
Alors je reçois un nouvel access token valide pour 15 minutes
|
|
Et je reçois un nouveau refresh token (rotation)
|
|
Et l'ancien refresh token est invalidé
|
|
|
|
Scénario: Refresh token expire après 30 jours d'inactivité
|
|
Étant donné que je me suis connecté il y a 30 jours
|
|
Et que je n'ai pas utilisé l'application depuis
|
|
Quand j'essaie d'utiliser mon refresh token
|
|
Alors la requête échoue
|
|
Et je dois me reconnecter avec email/password
|
|
|
|
Scénario: Prolongation automatique de la session si l'app est utilisée
|
|
Étant donné que je me suis connecté il y a 25 jours
|
|
Et que j'utilise l'application régulièrement
|
|
Quand je fais une requête API
|
|
Alors ma session est automatiquement prolongée
|
|
Et mon refresh token reste valide
|
|
|
|
Scénario: Détection de token replay attack
|
|
Étant donné que j'ai rafraîchi mon token
|
|
Et que j'ai reçu un nouveau refresh token
|
|
Quand j'essaie de réutiliser l'ancien refresh token
|
|
Alors la requête échoue
|
|
Et je vois le message "Token invalide ou révoqué"
|
|
Et toutes mes sessions sont révoquées par sécurité
|
|
|
|
Scénario: Voir la liste des appareils connectés
|
|
Étant donné que je suis connecté sur 3 appareils différents
|
|
Quand je consulte la liste de mes appareils connectés
|
|
Alors je vois 3 appareils avec les informations suivantes:
|
|
| information | exemple |
|
|
| OS | iOS 17.1 |
|
|
| Navigateur | Safari |
|
|
| Dernière connexion | Il y a 2 heures |
|
|
| Localisation | Paris, France (IP visible) |
|
|
|
|
Scénario: Révoquer un appareil spécifique
|
|
Étant donné que je suis connecté sur mon iPhone et mon iPad
|
|
Quand je révoque la session de mon iPad depuis les paramètres
|
|
Alors la session iPad est immédiatement déconnectée
|
|
Et ma session iPhone reste active
|
|
|
|
Scénario: Déconnecter tous les appareils sauf celui en cours
|
|
Étant donné que je suis connecté sur 4 appareils
|
|
Quand je clique sur "Déconnecter tous les appareils"
|
|
Alors les 3 autres appareils sont déconnectés
|
|
Et seul l'appareil actuel reste connecté
|
|
|
|
Scénario: Alerte de connexion depuis nouveau device
|
|
Étant donné que je me suis toujours connecté depuis Paris
|
|
Quand je me connecte depuis un nouvel appareil à Lyon
|
|
Alors je reçois une notification push sur mes autres appareils
|
|
Et je reçois un email avec:
|
|
| sujet | Nouvelle connexion détectée |
|
|
| localisation | Lyon, France |
|
|
| appareil | Android 14 - Chrome |
|
|
| action | Lien pour révoquer la session |
|
|
|
|
Scénario: Alerte de connexion suspecte depuis pays différent
|
|
Étant donné que je me suis toujours connecté depuis la France
|
|
Quand je me connecte depuis un appareil aux États-Unis
|
|
Alors je reçois une notification push immédiate
|
|
Et je reçois un email d'alerte de sécurité
|
|
Et la nouvelle session nécessite une validation 2FA même si désactivée
|
|
|
|
Scénario: Déconnexion après 30 jours d'inactivité totale
|
|
Étant donné que je ne me suis pas connecté depuis 30 jours
|
|
Quand j'ouvre l'application
|
|
Alors je suis automatiquement déconnecté
|
|
Et je dois me reconnecter avec email/password
|
|
Et je vois le message "Session expirée après 30 jours d'inactivité"
|
|
|
|
Scénario: Sessions multiples simultanées autorisées
|
|
Étant donné que je suis connecté sur:
|
|
| appareil |
|
|
| iPhone |
|
|
| iPad |
|
|
| PC Windows (Web) |
|
|
Quand je fais des actions sur les 3 appareils simultanément
|
|
Alors toutes les sessions fonctionnent sans conflit
|
|
Et chaque appareil maintient sa propre session
|
|
|
|
Scénario: Validation de JWT via Zitadel
|
|
Étant donné que j'ai reçu un access token JWT
|
|
Quand l'API RoadWave valide le token
|
|
Alors la validation est faite localement avec la clé publique Zitadel
|
|
Et aucune requête externe n'est effectuée (performance)
|
|
Et le token contient les claims suivants:
|
|
| claim | valeur_exemple |
|
|
| sub | user-id-123 |
|
|
| email | user@test.fr |
|
|
| exp | timestamp + 15 minutes |
|
|
| iss | zitadel.roadwave.com |
|