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.
Então, se você está construindo tudo isso, qual é o grande problema em criar um pequeno plugin para servir algumas configurações em modo somente leitura em uma rota personalizada?
Na minha opinião, o comportamento do Discourse em relação a isso deveria ser alterado, daí o Pedido de Funcionalidade. Na minha opinião, um plugin não deveria ser necessário.
Tenho uma solução alternativa sem o plugin, então as coisas funcionam, embora de uma maneira menos desejável. Quanto ao plugin, ele está chegando, mas com um conjunto adicional de recursos configuráveis dentro do plugin.
Também não faz sentido para mim, desculpe pela confusão de palavras.