Por lo que entiendo, es un comportamiento esperado de Discourse que se requiera acceso de administrador para /site/settings.json y para cierta información en /site.json.
Discussion Bridge y otras integraciones similares necesitan un conjunto limitado de información de configuración del sitio para diagnósticos rutinarios, planificación y sincronización. Actualmente, esto puede requerir el uso de una clave de API asociada a un administrador. Una clave de administrador de solo lectura evita las escrituras, pero aún así puede exponer todo lo que el administrador puede leer. Una clave de administrador global conlleva un riesgo innecesariamente alto para las operaciones diarias de máquinas.
¿Podría Discourse proporcionar:
Un alcance de clave de API granular que otorgue a los usuarios de integración no administradores acceso de lectura a un subconjunto adecuado y seguro de /site.json y /site/settings.json; o
Un punto final separado que contenga la información de configuración no sensible que las integraciones necesitan habitualmente?
Discourse ya admite claves de API de usuario para usuarios regulares, pero eso no resuelve este caso: una clave solo puede ejercer los permisos que el usuario asociado ya tenga. Por lo tanto, la solicitud es específicamente para una autorización segura de no administrador a los datos limitados de configuración del sitio que las integraciones necesitan, no simplemente otra forma de generar una clave.
El objetivo no es exponer configuraciones administrativas privadas. Se trata de permitir que una cuenta de integración autorizada y no administradora inspeccione la estructura del sitio y la configuración operativa que necesita, sin requerir credenciales de nivel de administrador para uso rutinario.
Esto reduciría el riesgo de credenciales, apoyaría integraciones con el principio de menor privilegio y facilitaría la operación segura de herramientas duraderas de máquina a máquina.
Nuestra organización tiene miembros que les encantaría poder ayudar, pero para implementar lo que se han ofrecido a ayudar a hacer, necesitarían tener acceso de administrador. Esto hace que sea muy difícil proporcionar todas las características y servicios que muy bien podríamos implementar si solo tuviéramos una manera de definir de manera más granular los permisos y el acceso. Necesitamos ser muy restrictivos en cómo otorgamos el acceso por varias razones, lo que aumenta la presión sobre los administradores para “hacer todas las cosas” cuando hay configuraciones del sitio no destructivas que algunos de nuestros miembros podrían ayudar fácilmente a gestionar… pero no pueden hacerlo.
¿Podrías ser más específico sobre qué ajustes exactos del sitio?
El acceso de solo lectura sin restricciones a todos los ajustes del sitio parece una herramienta algo tosca e incluiría algunos muy sensibles, incluidas las claves de SaaS.
¿Podrías crear un plugin con acceso de solo lectura por grupo a un conjunto específico y nombrado de ajustes del sitio?
Esa es precisamente la razón por la que la falta de acceso para usuarios no administradores hace que el método habitual no funcione, de ahí mi solicitud.
El objetivo es realizar la tarea de integración, accediendo y configurando los ajustes necesarios sin utilizar una clave de ámbito global empleada por un usuario administrador ni una clave de ámbito granular utilizada por un usuario administrador.
La clave de ámbito granular resulta de poca ayuda para restringir el acceso si aún tengo que vincularla a un usuario administrador. Espero que esto aclare las cosas.
Tu sugerencia de utilizar un complemento es buena, pero no deseo un complemento con el conjunto de características actual. No quiero que el usuario de Astro tenga que instalar un complemento para conectarse con Discourse.
¿Podrías reformularlo?