b711e654b3
Clos : GET /api/Instance/{id} renvoyait 403 à l'app visiteur. Une clé API donne
maintenant accès à sa seule instance, en vue réduite — plan, quotas, TVA,
facturation et pinCode retirés. Déployé en version-3.1.3 et vérifié en préprod
sur cinq cas d'autorisation.
La carte close garde le piège qui vaut pour tout le projet : le test « est-ce un
utilisateur du manager » ne peut pas se baser sur un claim de permission, parce
qu'AuthorizationMiddleware peuple HttpContext.User depuis le schéma ApiKey avant
de court-circuiter sur [AllowAnonymous]. Et elle rectifie une affirmation fausse
de la première rédaction : StripeCustomerId n'est pas exposé par ToDTO.
Nouveau, en Urgent : GET /api/Configuration répond 200 sans aucune clé. Ce n'est
pas une clé mal vérifiée mais un [AllowAnonymous] explicite, probablement hérité
de la v2. Le périmètre exact reste à établir — les autres routes que consomment
les apps visiteur n'ont pas été passées en revue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5 lines
2.1 KiB
Markdown
5 lines
2.1 KiB
Markdown
---
|
|
title: L'app visiteur lit le détail d'instance, en vue réduite
|
|
---
|
|
<span><strong>Corrigé le 08/09.</strong> <code>GET /api/Instance/{id}</code> renvoyait 403 à <code>mymuseum-visitapp</code>, qui l'appelle au démarrage pour la voix du guide : tout <code>InstanceController</code> porte <code>[Authorize(SuperAdmin)]</code> et <code>GetDetail</code> n'avait pas d'exception, contrairement à <code>slug</code>, <code>byPin</code> et <code>app-key</code>. Une clé API donne désormais accès à <strong>sa seule instance</strong> — clé croisée = 403 — et à une vue réduite : <code>StripCommercialFields</code> retire plan, quotas, usage IA, essai, TVA, facturation et le <code>pinCode</code>, qui ouvre l'appairage des tablettes. Le manager continue de tout voir.<br><br><strong>Le piège, qui vaut pour tout le projet</strong> : le test « est-ce un utilisateur du manager » ne peut PAS se baser sur un claim de permission. <code>AuthorizationMiddleware</code> authentifie avec les schémas de la policy du contrôleur — <code>JwtBearer</code> <em>et</em> <code>ApiKey</code> — et peuple <code>HttpContext.User</code> <strong>avant</strong> de court-circuiter sur <code>[AllowAnonymous]</code>. Une clé API produit donc un <code>User</code> authentifié auquel le handler pose le claim <code>Viewer</code> : la première version laissait passer tout le monde. Elle ne se voyait pas, parce que les champs sensibles de l'instance testée étaient <em>naturellement</em> nuls — c'est le test croisé sur une instance avec un <code>pinCode</code> qui l'a révélée. Le test porte maintenant sur le schéma d'authentification.<br><br>⛔ <strong>Rectification</strong> : la carte annonçait une fuite de <code>StripeCustomerId</code> et <code>StripeSubscriptionId</code>. C'est faux — ils sont sur l'entité mais <strong>pas exposés par <code>ToDTO</code></strong>. Ce qui fuyait vraiment : plan, quotas, TVA, facturation, <code>pinCode</code>.<br><br>Vérifié sur la préprod, cinq cas : 401 sans clé, 200 sur sa propre instance, 403 en croisé dans les deux sens, 200 pour le manager avec le DTO complet. Déployé en <code>version-3.1.3</code>.</span>
|