Como eu entendo, exigir acesso de administrador para /site/settings.json e algumas informações em /site.json é um comportamento esperado do Discourse.
A Discussion Bridge e integrações semelhantes precisam de um conjunto limitado de informações de configuração do site para diagnósticos de rotina, planejamento e sincronização. Atualmente, isso pode exigir o uso de uma chave de API associada a um administrador. Uma chave de administrador de somente leitura impede gravações, mas ainda pode expor tudo o que o administrador pode ler. Uma chave de administrador global carrega um risco desnecessariamente grande para operações diárias de máquinas.
O Discourse poderia fornecer:
Um escopo de chave de API granular que dê aos usuários de integração não administradores acesso de leitura a um subconjunto apropriado e seguro de /site.json e /site/settings.json; ou
Um endpoint separado contendo as informações de configuração não sensíveis que as integrações normalmente precisam?
O Discourse já suporta chaves de API de usuário para usuários comuns, mas isso não resolve este caso: uma chave só pode exercer permissões que o usuário associado já possui. Portanto, a solicitação é especificamente por autorização não administradora segura para os dados limitados de configuração do site que as integrações precisam — não simplesmente outra maneira de gerar uma chave.
O objetivo não é expor configurações administrativas privadas. É permitir que uma conta de integração não administradora autorizada inspecione a estrutura do site e as configurações operacionais de que precisa sem exigir credenciais de nível de administrador de rotina.
Isso reduziria o risco de credenciais, apoiaria integrações de menor privilégio e facilitaria a operação segura de ferramentas duradouras de máquina para máquina.
Nossa organização tem membros que adorariam poder ajudar, mas para implementar o que eles se ofereceram para ajudar, seria necessário que eles tivessem acesso de administrador. Isso torna muito difícil fornecer todos os recursos e serviços que poderíamos muito bem implementar se apenas tivéssemos uma maneira de delimitar permissões e acessos de forma mais granular. Precisamos ser muito restritivos sobre como concedemos acesso por uma série de razões, o que aumenta a pressão sobre os administradores para “fazerem todas as coisas”, quando existem configurações de site não destrutivas que alguns de nossos membros poderiam facilmente ajudar a gerenciar… mas eles não podem.
Você poderia ser mais específico sobre quais configurações exatas do site?
O acesso irrestrito somente para leitura a todas as configurações do site parece um pouco uma solução bruta e incluiria algumas muito sensíveis, incluindo as chaves SaaS.
Você poderia criar um plugin com acesso somente para leitura por grupo a um conjunto específico nomeado de configurações do site?
O objetivo é realizar o trabalho de integração, acessando e configurando as definições necessárias sem usar uma chave de escopo global utilizada por um usuário administrador ou uma chave de escopo granular usada por um usuário administrador.
A chave de escopo granular é menos útil para limitar o acesso se eu ainda tiver que vinculá-la a um usuário administrador. Espero que isso ajude.
Sua sugestão de usar um plugin é uma boa, no entanto, não quero um plugin com o conjunto de funcionalidades atual. Não quero que o usuário do Astro precise instalar um plugin para se conectar ao Discourse.
poderia reformular?