mymuseum-visitapp appelle GET /api/Instance/{id} au démarrage pour lire la voix
du guide, et recevait un 403 : tout InstanceController porte [Authorize(SuperAdmin)]
et GetDetail n'avait pas d'exception, contrairement à slug, byPin et app-key.
Une clé API donne désormais accès à SON instance seulement — clé croisée = 403 —
et à une vue réduite. StripCommercialFields retire le plan, les quotas, l'usage
IA, l'essai, la TVA, la facturation et le pinCode, qui ouvre l'appairage des
tablettes. Un utilisateur du manager continue de tout voir.
⚠️ Le test « est-ce un utilisateur du manager » ne peut PAS se baser sur un claim
de permission. AuthorizationMiddleware authentifie avec les schémas de la policy
du contrôleur — JwtBearer ET ApiKey — et peuple HttpContext.User AVANT de
court-circuiter sur [AllowAnonymous]. Une clé API produit donc un User
authentifié auquel le handler pose le claim Viewer : la première version du
correctif laissait passer tout le monde, et ne se voyait pas sur une instance
dont les champs sensibles sont naturellement nuls. Le test porte donc sur le
schéma d'authentification.
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.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
847f81393b