Workflow connexion et accès
Workflow connexion et accès
Ce workflow détermine ce qu'un utilisateur peut faire après connexion.
sequenceDiagram
participant U as Utilisateur
participant F as Frontal
participant T as Plateforme TARS
participant O as Organisation
U->>F: Saisit ses identifiants
F->>T: Demande de connexion
T->>T: Vérifie compte, statut, mot de passe
T-->>F: Session ouverte
F->>T: Charge le profil
T->>O: Identifie organisations disponibles
T-->>F: Droits selon organisation active
U->>F: Change d'organisation si besoin
F->>T: Recalcule les droits
Étapes
| Étape | Règle |
|---|---|
| Identification | L'utilisateur doit être reconnu (identifiant = adresse email, mot de passe) |
| Vérification statut | Le compte ne doit pas être au statut BLOCKED |
| Chargement organisations | L'utilisateur ne voit que ses organisations |
| Choix du contexte | L'organisation active détermine les droits |
| Vérification de la plateforme | Le profil doit pouvoir accéder à la plateforme demandée (admin, espace personnel) avant toute vérification d'accès plus fine |
| Calcul des droits | Rôles, contrats et access keys sont pris en compte |
| Navigation | Les frontaux masquent ou bloquent les actions non autorisées; une route protégée qui déclare une liste d'accès requis redirige vers une page d'erreur si aucun de ces accès n'est présent |
Règles de mot de passe
Un mot de passe doit compter au moins 8 caractères et inclure au moins un chiffre, une minuscule, une majuscule et un caractère spécial parmi $ & + , : ; = ? @ # | ' < > . ^ * ( ) % ! -. Cette règle s'applique à la création de compte comme au changement de mot de passe; lors d'un changement, le nouveau mot de passe doit en plus être différent du mot de passe actuel, et le mot de passe actuel est vérifié avant d'accepter le changement.
Une case « Se souvenir de moi » à la connexion prolonge la durée de la session (jusqu'à 180 jours) au lieu de la durée de session par défaut.
Statuts de compte
| Statut personne | Signification |
|---|---|
TO_VALIDATE | Compte créé, en attente de validation |
EMAIL_VALIDATED | Email confirmé |
MOBILE_VALIDATED | Email et mobile confirmés |
VALIDATED | Compte validé |
COMPLETED | Parcours d'inscription complet |
DISABLED | Compte désactivé |
BLOCKED | Compte bloqué, connexion et actions refusées |
ARCHIVED | Compte archivé |
Un compte ne peut être débloqué que s'il est au statut BLOCKED; un compte peut être bloqué depuis n'importe quel statut de la progression normale, sauf s'il est déjà BLOCKED. Le blocage et le déblocage d'un compte, côté admin, exigent l'accès ORGANISATION_USER_MANAGE sur l'organisation de la personne concernée.
Calcul observé
| Source de droit | Effet appliqué |
|---|---|
| Contrats actifs | Donnent les droits de base de l'organisation |
| Contrats parents transmissibles | Peuvent étendre les droits d'une organisation enfant |
| Organisation active | Limite les droits au contexte choisi par l'utilisateur, par intersection en cas de procuration ou d'organisation descendante; une procuration par rôles métier ne laisse passer que les accès des rôles délégués |
| Rôles métier de la personne | Restreignent les droits du contrat à ceux que réunissent les rôles attribués |
| Accès personnalisés | Restreignent les droits du contrat à la liste cochée sur la fiche; les rôles sont alors ignorés |
| Shop | Les droits sont calculés et vérifiés séparément pour chaque shop |
| Profil super admin | Ouvre tous les droits disponibles sur les shops |
Les accès personnalisés et les rôles ne peuvent que restreindre les droits ouverts par les contrats, jamais les étendre. Le détail est décrit dans Calcul des droits d'accès.
Cas de refus
- Identifiants incorrects.
- Compte bloqué.
- Organisation bloquée.
- Aucun droit pour l'action demandée.
- Contrat manquant ou inactif.
- Objet demandé hors périmètre de l'organisation.
Effet métier
Une même personne peut voir des choses différentes selon l'organisation active. Par exemple, elle peut être acheteur dans une organisation, vendeur dans une autre et simple lecteur dans une troisième.
Limite de vérification
La vérification des identifiants elle-même (mot de passe, éventuelle limitation du nombre de tentatives, mécanismes anti-fraude à la connexion) est réalisée côté serveur, hors du périmètre du dépôt front-end audité pour cette page. Ce qui est vérifié et confirmé dans le code front-end (tars-monorepo) : la règle de complexité du mot de passe, la progression des statuts de compte, la condition de déblocage, la vérification de plateforme et le blocage de navigation par route.