Comment Sushi SaaS route les requêtes

Le middleware Sushi SaaS gère le contexte de requête, pas l’authentification ni l’autorisation métier. Ses trois tâches—locale, corrélation et transport d’organisation—créent un comportement visible que vous devez choisir consciemment.

Ce que voit l’utilisateur

• Une page arrive sur la bonne route localisée via next-intl.
• Deux onglets peuvent rester sur deux workspaces car l’organisation est exprimée par ?org=<slug>, pas seulement dans la session.
• Un lien de compte partagé indique le workspace visé.

Chaque réponse inclut x-request-id, ce qui relie une demande support aux logs structurés. Les requêtes API évitent la négociation de langue mais reçoivent le même contexte de requête et d’organisation.

L’implémentation est dans src/middleware.ts au commit 7580470.

Ce que le middleware considère fiable

Pour une page, l’organisation vient du query parameter ; un header d’organisation fourni par l’appelant est supprimé. Pour une API, le client partagé peut envoyer x-organization-slug ; la valeur URL est prioritaire si les deux existent.

Aucune ne donne l’autorisation. src/services/authz.ts prouve toujours l’appartenance et refuse les APIs ambiguës pour un utilisateur multi-organisations. Le middleware vérifie seulement que le contexte peut être transporté.

Un request ID entrant n’est accepté qu’avec une longueur et un format sûrs ; sinon un UUID est créé. Il est transmis à la route et copié sur la réponse.

Vos choix

Routage par locale

Gardez next-intl si les pages préfixées et la détection font partie du produit. Pour une seule langue, retirez la branche avec routes localisées, catalogues et tests. Un contrat à moitié supprimé produit des redirects et liens contradictoires.

Sélection du workspace

Le query string livré est propre à chaque onglet et facile à ajouter aux URLs existantes. Un tenant dans le path comme /acme/account donne une hiérarchie plus forte, mais exige de changer liens, callbacks, matchers et résolution. La session seule paraît simple, mais deux onglets peuvent écraser la même organisation active ; utilisez-la seulement si ce comportement convient.

Traçage

Gardez les IDs de corrélation dans presque tout produit déployé. Si votre proxy ou outil d’observabilité possède les trace IDs, mappez sa valeur fiable ou gardez les deux. N’acceptez jamais de texte appelant non borné dans les logs.

Contexte API

Exiger l’organisation pour un utilisateur multi-workspaces évite qu’une opération tombe silencieusement dans le dernier tenant actif. Simplifiez uniquement si l’API est certainement mono-tenant.

Quand ajouter une logique middleware

Ajoutez un sujet seulement s’il doit précéder le routage et reste rapide et edge-compatible. L’appartenance, l’autorisation en base, la facturation et les règles métier vont dans les services.

Après modification, testez pages localisées, /api, assets, transmission du request ID, contexte malformé et deux onglets. Relisez Architecture et contrats d’erreur et Organisations et équipes.