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.json et /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.
Au sein de notre organisation, certains membres seraient ravis de pouvoir nous aider, mais mettre en œuvre ce qu’ils ont proposé nécessiterait qu’ils disposent d’un accès administrateur. Cela rend très difficile la mise en place de toutes les fonctionnalités et services que nous pourrions très bien développer si seulement nous avions un moyen de définir les permissions et les accès de manière plus fine. Nous devons être très restrictifs dans la façon dont nous accordons l’accès, pour de nombreuses raisons, ce qui augmente la pression sur les administrateurs pour « tout faire », alors qu’il existe des paramètres de site non destructifs que certains de nos membres pourraient facilement aider à gérer… mais ils ne le peuvent pas.
Pourriez-vous être plus précis quant aux paramètres exacts du site ?
Un accès en lecture seule sans restriction à tous les paramètres du site semble être un instrument un peu trop brut et inclurait certains paramètres très sensibles, notamment les clés SaaS.
Pourriez-vous créer un plugin offrant un accès en lecture seule par groupe à un ensemble spécifique de paramètres du site ?
L’objectif est d’effectuer les tâches d’intégration, en accédant et en configurant les paramètres requis sans utiliser une clé à portée globale utilisée par un utilisateur administrateur ou une clé à portée granulaire utilisée par un utilisateur administrateur.
La clé à portée granulaire est moins utile pour limiter l’accès si je dois toujours l’associer à un utilisateur administrateur. J’espère que cela aide.
Votre suggestion d’utiliser une extension est bonne, mais je ne souhaite pas une extension avec l’ensemble de fonctionnalités actuel. Je ne veux pas que l’utilisateur d’Astro doive installer une extension pour se connecter à Discourse.
pourrais-tu reformuler ?