Pipeline de requêtes

Les contrôles d'authentification, d'autorisation et de limitation de débit partagés que chaque requête API traverse.

Chaque requête API passe par le même parcours avant qu'une quelconque logique métier ne s'exécute. Ces contrôles sont des implémentations uniques et réutilisables — pas du code par route — afin que la sécurité se comporte de manière cohérente sur l'ensemble de la surface.

Les contrôles

Middleware — vérifie la présence de la session, applique la politique de sécurité du contenu (Content Security Policy) et court-circuite en mode maintenance.

Authentification — vérifie le cookie de session Firebase (ou un JWT interne pour les appels service-à-service) et réconcilie l'utilisateur en base de données. Échoue avec 401.

Autorisation (RBAC) — résout le niveau d'accès le plus élevé de l'appelant pour l'entité cible (lecture < écriture < admin), limité à l'espace de travail. Échoue avec 403.

Limitation de débit — un compteur à fenêtre glissante sur les routes coûteuses et publiques. Échoue avec 429.

Handler — la requête validée atteint la logique métier vérifiée par Zod.

Flux de requête

sequenceDiagram
    autonumber
    actor C as Caller
    participant E as Edge
    participant G as API Guards
    participant A as Auth
    participant Z as RBAC
    participant L as Rate Limiter
    participant H as Handler

    C->>E: HTTPS request
    E->>G: Route handler
    G->>A: requireApiAuth()
    A-->>G: session or null
    alt not authenticated
        G-->>C: 401 Unauthorized
    else authenticated
        G->>Z: requireWorkspaceAccess(min)
        Z-->>G: permission or null
        alt insufficient permission
            G-->>C: 403 Forbidden
        else authorized
            G->>L: checkRateLimit(key)
            alt limit exceeded
                L-->>C: 429 Too Many Requests
            else within limit
                G->>H: validated request
                H-->>C: 200 + data
            end
        end
    end

Stockage de la limitation de débit

Le limiteur utilise par défaut une fenêtre en mémoire locale au processus. Lorsqu'une URL Redis est configurée, il bascule vers une fenêtre glissante basée sur Memorystore (Lua atomique) partagée entre toutes les instances de serveur, afin qu'un seul utilisateur ne puisse pas dépasser sa limite en répartissant les requêtes sur plusieurs réplicas.

Le client Redis se connecte de manière différée et le limiteur bascule en mode dégradé vers la mémoire — une panne du cache ne peut jamais interrompre le démarrage ni provoquer une erreur 500 sur une requête. Il se dégrade vers des limites par instance jusqu'à ce que Redis se rétablisse.

Isolation des locataires

L'autorisation est toujours limitée à l'espace de travail. Un accès est une ligne indexée par (userId, entityType, entityId), et l'exécuteur propage userId et workspaceId tout au long de l'exécution — ainsi, un workflow ne peut lire et écrire des données qu'à l'intérieur de la limite de son propre locataire. Voir Multi-location.

Pipeline de requêtes

Les contrôles

Flux de requête

Stockage de la limitation de débit

Isolation des locataires

On this page