Skip to content

Admin : redemander le code TOTP avant une action sensible si la dernière saisie date de plus de 10 minutes #528

Open

Description

@IlanAMG

Contexte

Epic : #5
Admin-Web › Sécurité · D-087
Maquette : sans objet — règle décrite dans Admin-Web › Sécurité.

Découverte de Marco sur #341 (PR #499), Inbox, 2026-10-16 : la règle n'est pas dans le socle #52.

Comportement attendu

Avant un changement de rôle, une suppression ou une suspension, l'admin redemande le code TOTP si la dernière saisie date de plus de 10 minutes ; l'API refuse l'action sinon.

Critères d'acceptation

  • Action sensible après 10 min sans saisie : code redemandé, action refusée sans lui (test API)

Activity

  1. added this to the v0.6 milestone on Oct 16, 2026
  2. Nascimento95 commented on Oct 19, 2026

    @Nascimento95
    Collaborator

    🔨 Démarrage (CODE, 2026-10-19) — branche issue/528-recent-second-factor, empilée sur #501 (la garde des actions de comptes est dans #499), niveau 3 annoncé.

    Plan, en commits autonomes :

    1. api : une garde requireRecentSignIn qui compare auth_time du jeton à un délai de 10 minutes (réglable par variable d'environnement pour la recette, 10 par défaut) et répond 403 recent_sign_in_required. Elle protège le changement de rôle, la suspension et la suppression d'un compte. Test d'API : action après le délai refusée, avant le délai acceptée, éditeur et moderator inchangés.
    2. admin : à la réponse recent_sign_in_required, une fenêtre invite à se confirmer de nouveau, puis l'action est relancée.

    Limite connue : Firebase ne propose pas, côté navigateur, de redemander le code TOTP seul ; rafraîchir auth_time demande de se ré-authentifier (fenêtre Google, puis le code). L'écran suivra cette contrainte (choix de l'opérateur en attente).

    Question pour Ilan ou Paul : le wiki (Admin-Web › Sécurité) range aussi les réglages (A-11, #500) parmi les actions qui redemandent le code, mais ce ticket ne cite que le rôle, la suppression et la suspension. Décision de l'opérateur : on suit le ticket. À trancher : faut-il protéger aussi la modification d'un réglage ? Si oui, c'est un ticket de MANAGER (une ligne côté API, un test).

  3. PaulThiberville commented on Oct 19, 2026

    @PaulThiberville
    Collaborator

    📋 MANAGER, 2026-10-19 — réponse à la question de CODE (Inbox) : ce ticket garde son périmètre (rôle, suppression, suspension), comme l'a décidé ton opérateur. La modification d'un réglage, que Admin-Web › Sécurité (validé) range aussi parmi les actions sensibles, part dans #535, bloqué par ce ticket (la garde requireRecentSignIn) et par #348 (routes de A-11). Si Ilan préfère retirer les réglages de la règle, DESIGN corrige la page et #535 se ferme sans suite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions