# Предложение: разрешить безопасный доступ к настройкам сайта через API без ключа администратора
**URL:** https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523
**Category:** Feature
**Tags:** rest-api
**Created:** [25.Июль.2026 23:03:41 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523 "2026-07-25T23:03:41Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [25.Июль.2026 23:03:41 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/1 "2026-07-25T23:03:41Z")
Насколько я понимаю, требование административного доступа для `/site/settings.json` и некоторых данных в `/site.json` является ожидаемым поведением Discourse.
Discussion Bridge и аналогичные интеграции нуждаются в ограниченном наборе конфигурационных данных сайта для рутинной диагностики, планирования и синхронизации. На данный момент это может требовать использования API-ключа, связанного с администратором. Ключ только для чтения предотвращает запись, но всё равно может раскрывать всё, что может читать администратор. Глобальный ключ администратора несёт излишний риск для повседневных машинных операций.
Может ли Discourse предоставить:
- Иерархическую область действия API-ключа, дающую пользователям интеграции без прав администратора доступ на чтение к соответствующему безопасному подмножеству `/site.json` и `/site/settings.json`; или
- Отдельный конечный пункт (endpoint), содержащий конфиденциальные конфигурационные данные, которые обычно требуются интеграциям?
Discourse уже поддерживает пользовательские API-ключи для обычных пользователей, но это не решает данную задачу: ключ может использовать только те разрешения, которые уже есть у связанного пользователя. Таким образом, запрос касается именно безопасного неадминистративного авторизации для ограниченных конфигурационных данных сайта, необходимых интеграциям, а не просто другого способа генерации ключа.
Цель — не раскрыть частные административные настройки. Речь идёт о том, чтобы авторизованная учётная запись интеграции без прав администратора могла просматривать структуру сайта и операционные настройки, которые ей нужны, без необходимости использования рутинных учётных данных уровня администратора.
Это снизит риск компрометации учётных данных, поддержит интеграции с наименьшими привилегиями и упростит безопасную работу долговечных машинных инструментов.
Фон: [Confirming API Access to Authoring Limit Site Settings](https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937)
---
### Author:  [@jenmck](https://meta.discourse.org/u/jenmck)
#### Post date: [26.Июль.2026 08:19:24 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/2 "2026-07-26T08:19:24Z")
Огромное +1 за это!
В нашей организации есть участники, которые с радостью помогли бы, но для реализации того, что они предложили, им потребуется доступ администратора. Из-за этого нам очень сложно предоставлять все функции и услуги, которые мы вполне могли бы внедрить, если бы у нас был способ более гибко настраивать права и доступ. По ряду причин мы должны быть очень строгими в предоставлении доступа, что увеличивает нагрузку на администраторов, вынуждая их «делать всё подряд», хотя некоторые участники могли бы легко помочь в управлении настройками сайта, которые не несут риска для системы… но у них нет такой возможности.
Спасибо, что поделились этим!
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [26.Июль.2026 09:34:25 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/3 "2026-07-26T09:34:25Z")
Не могли бы вы уточнить, какие именно настройки сайта?
Неограниченный доступ только для чтения ко всем настройкам сайта кажется несколько грубым инструментом и включал бы некоторые очень конфиденциальные настройки, включая ключи SaaS.
Вы могли бы создать плагин с доступом только для чтения для группы к конкретному набору именованных настроек сайта?
Это был бы относительно небольшой плагин.
---
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [27.Июль.2026 00:06:45 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/4 "2026-07-27T00:06:45Z")
> [@merefield](#):
>
> Не могли бы вы уточнить, какие именно настройки сайта вы имеете в виду?
Вы спрашиваете меня или @jenmck?
[quote=“merefield, post:3, topic:408523”]
Безоговорочный доступ только для чтения ко всем настройкам сайта кажется несколько грубым инструментом
[/quote]\nИменно это отсутствие доступа для обычных пользователей к стандартным настройкам и обусловливает мой запрос. 🙂
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [27.Июль.2026 00:10:25 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/5 "2026-07-27T00:10:25Z")
> [@philh](#):
>
> Ты спрашиваешь меня или @jenmck?
Тебя.
> [@philh](#):
>
> Вот именно отсутствие доступа для обычных пользователей делает невозможным стандартный способ, поэтому я и обращаюсь с этой просьбой. 🙂
Я не совсем понимаю, что ты имеешь в виду 😕 не мог бы ты переформулировать?
---
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [27.Июль.2026 00:39:54 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/6 "2026-07-27T00:39:54Z")
Цель состоит в том, чтобы выполнить работу по интеграции, обращаясь к настройкам и устанавливая их, не используя ключ с глобальной областью видимости, принадлежащий пользователю-администратору, и не используя ключ с узкой областью видимости, также принадлежащий пользователю-администратору.
Ключ с узкой областью видимости мало помогает в ограничении доступа, если мне всё равно приходится привязывать его к пользователю-администратору. Надеюсь, это прояснит ситуацию.
Ваше предложение использовать плагин кажется хорошим, однако я не хочу использовать плагин с текущим набором функций. Я не хочу, чтобы пользователю Astro приходилось устанавливать плагин для подключения к Discourse.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [27.Июль.2026 06:25:29 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/7 "2026-07-27T06:25:29Z")
> [@philh](#):
>
> Discussion Bridge
Что это такое и к каким именно настройкам ему нужен доступ?
> [@philh](#):
>
> the Astro user
Кто такой пользователь Astro?
---
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [27.Июль.2026 18:28:05 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/8 "2026-07-27T18:28:05Z")
Ещё не совсем готово, но раз вы спросили
> **[Discussion Bridge](https://discussionbridge.dev/)**
>
> Discussion Bridge connects source-controlled publishing with durable Discourse community discussion.
SSG
> **[Astro](https://astro.build/)**
>
> Astro builds fast content sites, powerful web applications, dynamic server APIs, and everything in-between.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [27.Июль.2026 18:40:29 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/9 "2026-07-27T18:40:29Z")
Итак, если вы разрабатываете всё это, в чём же проблема создать небольшой плагин для предоставления некоторых настроек в режиме только для чтения по специальному маршруту?
---
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [27.Июль.2026 20:03:59 UTC](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523/10 "2026-07-27T20:03:59Z")
> [@philh](#):
>
> Цель состоит в том, чтобы выполнить работу по интеграции, получая доступ к необходимым настройкам и изменяя их, не используя глобальный ключ с правами администратора и не используя ключ с ограниченной областью видимости, привязанный к пользователю-администратору.
> Ключ с ограниченной областью видимости не очень помогает в ограничении доступа, если мне всё равно приходится привязывать его к пользователю-администратору.
По моему мнению, поведение Discourse в этом вопросе должно быть изменено, поэтому я и отправил запрос на добавление функции. По моему мнению, плагин не должен быть обязательным.
У меня есть обходное решение без использования плагина, поэтому всё работает, хотя и не так, как хотелось бы. Что касается плагина, он появится, но будет включать в себя дополнительный набор настраиваемых функций.
> [@merefield](#):
>
> > [@philh](#):
> >
> > Разве текущее отсутствие доступа для пользователей без прав администратора не делает обычный способ невозможным, что и является причиной моего запроса? 🙂
>
> Я не понимаю, что вы имеете в виду 😕 не могли бы вы переформулировать?
Мне тоже это не совсем ясно, извините за эту путаницу. 😀