Si je comprends bien, le fait d’exiger un accès administrateur pour /site/settings.json et certaines informations dans /site.json correspond au comportement attendu de Discourse.
Discussion Bridge et des intégrations similaires ont besoin d’un ensemble limité d’informations de configuration du site pour le diagnostic, la planification et la synchronisation de routine. Aujourd’hui, cela peut nécessiter l’utilisation d’une clé API associée à un administrateur. Une clé en lecture seule empêche les écritures, mais elle peut toujours exposer tout ce que l’administrateur peut lire. Une clé d’administrateur global comporte un risque inutilement élevé pour les opérations quotidiennes des machines.
Discourse pourrait-il fournir :
- Un champ d’application granulaire de clé API accordant aux utilisateurs d’intégration non administrateurs un accès en lecture à un sous-ensemble approprié et sûr de
/site.jsonet/site/settings.json; ou - Un point de terminaison séparé contenant les informations de configuration non sensibles dont les intégrations ont couramment besoin ?
Discourse prend déjà en charge les clés API utilisateur pour les utilisateurs réguliers, mais cela ne résout pas ce cas : une clé ne peut exercer que les permissions que l’utilisateur associé possède déjà. La demande vise donc spécifiquement une autorisation non administrative sûre pour les données de configuration limitées dont les intégrations ont besoin — et non simplement une autre façon de générer une clé.
L’objectif n’est pas d’exposer les paramètres administratifs privés. Il s’agit de permettre à un compte d’intégration non administrateur autorisé d’inspecter la structure du site et les paramètres opérationnels dont il a besoin, sans exiger de credentials administratifs de routine.
Cela réduirait le risque lié aux identifiants, prendrait en charge les intégrations au principe du moindre privilège et faciliterait l’exploitation sécurisée d’outils machine-à-machine durables.
Contexte : Confirming API Access to Authoring Limit Site Settings