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.jsone/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.
Contexto: Confirming API Access to Authoring Limit Site Settings