Насколько я понимаю, требование административного доступа для /site/settings.json и некоторых данных в /site.json является ожидаемым поведением Discourse.
Discussion Bridge и аналогичные интеграции нуждаются в ограниченном наборе конфигурационных данных сайта для рутинной диагностики, планирования и синхронизации. На данный момент это может требовать использования API-ключа, связанного с администратором. Ключ только для чтения предотвращает запись, но всё равно может раскрывать всё, что может читать администратор. Глобальный ключ администратора несёт излишний риск для повседневных машинных операций.
Может ли Discourse предоставить:
Иерархическую область действия API-ключа, дающую пользователям интеграции без прав администратора доступ на чтение к соответствующему безопасному подмножеству /site.json и /site/settings.json; или
Отдельный конечный пункт (endpoint), содержащий конфиденциальные конфигурационные данные, которые обычно требуются интеграциям?
Discourse уже поддерживает пользовательские API-ключи для обычных пользователей, но это не решает данную задачу: ключ может использовать только те разрешения, которые уже есть у связанного пользователя. Таким образом, запрос касается именно безопасного неадминистративного авторизации для ограниченных конфигурационных данных сайта, необходимых интеграциям, а не просто другого способа генерации ключа.
Цель — не раскрыть частные административные настройки. Речь идёт о том, чтобы авторизованная учётная запись интеграции без прав администратора могла просматривать структуру сайта и операционные настройки, которые ей нужны, без необходимости использования рутинных учётных данных уровня администратора.
Это снизит риск компрометации учётных данных, поддержит интеграции с наименьшими привилегиями и упростит безопасную работу долговечных машинных инструментов.
В нашей организации есть участники, которые с радостью помогли бы, но для реализации того, что они предложили, им потребуется доступ администратора. Из-за этого нам очень сложно предоставлять все функции и услуги, которые мы вполне могли бы внедрить, если бы у нас был способ более гибко настраивать права и доступ. По ряду причин мы должны быть очень строгими в предоставлении доступа, что увеличивает нагрузку на администраторов, вынуждая их «делать всё подряд», хотя некоторые участники могли бы легко помочь в управлении настройками сайта, которые не несут риска для системы… но у них нет такой возможности.
Не могли бы вы уточнить, какие именно настройки сайта?
Неограниченный доступ только для чтения ко всем настройкам сайта кажется несколько грубым инструментом и включал бы некоторые очень конфиденциальные настройки, включая ключи SaaS.
Вы могли бы создать плагин с доступом только для чтения для группы к конкретному набору именованных настроек сайта?
[quote=“merefield, post:3, topic:408523”]
Безоговорочный доступ только для чтения ко всем настройкам сайта кажется несколько грубым инструментом
[/quote]\nИменно это отсутствие доступа для обычных пользователей к стандартным настройкам и обусловливает мой запрос.
Цель состоит в том, чтобы выполнить работу по интеграции, обращаясь к настройкам и устанавливая их, не используя ключ с глобальной областью видимости, принадлежащий пользователю-администратору, и не используя ключ с узкой областью видимости, также принадлежащий пользователю-администратору.
Ключ с узкой областью видимости мало помогает в ограничении доступа, если мне всё равно приходится привязывать его к пользователю-администратору. Надеюсь, это прояснит ситуацию.
Ваше предложение использовать плагин кажется хорошим, однако я не хочу использовать плагин с текущим набором функций. Я не хочу, чтобы пользователю Astro приходилось устанавливать плагин для подключения к Discourse.
не мог бы ты переформулировать?