Насколько я понимаю, требование административного доступа для /site/settings.json и некоторых данных в /site.json является ожидаемым поведением Discourse.
Discussion Bridge и аналогичные интеграции нуждаются в ограниченном наборе конфигурационных данных сайта для рутинной диагностики, планирования и синхронизации. На данный момент это может требовать использования API-ключа, связанного с администратором. Ключ только для чтения предотвращает запись, но всё равно может раскрывать всё, что может читать администратор. Глобальный ключ администратора несёт излишний риск для повседневных машинных операций.
Может ли Discourse предоставить:
- Иерархическую область действия API-ключа, дающую пользователям интеграции без прав администратора доступ на чтение к соответствующему безопасному подмножеству
/site.jsonи/site/settings.json; или - Отдельный конечный пункт (endpoint), содержащий конфиденциальные конфигурационные данные, которые обычно требуются интеграциям?
Discourse уже поддерживает пользовательские API-ключи для обычных пользователей, но это не решает данную задачу: ключ может использовать только те разрешения, которые уже есть у связанного пользователя. Таким образом, запрос касается именно безопасного неадминистративного авторизации для ограниченных конфигурационных данных сайта, необходимых интеграциям, а не просто другого способа генерации ключа.
Цель — не раскрыть частные административные настройки. Речь идёт о том, чтобы авторизованная учётная запись интеграции без прав администратора могла просматривать структуру сайта и операционные настройки, которые ей нужны, без необходимости использования рутинных учётных данных уровня администратора.
Это снизит риск компрометации учётных данных, поддержит интеграции с наименьшими привилегиями и упростит безопасную работу долговечных машинных инструментов.