Подтверждение доступа к API для настроек ограничений авторства сайта

Разработка
1

Я работаю над интеграцией, которая публикует и синхронизирует сопутствующие темы в Discourse через API. Для диагностики настройки я хочу прочитать текущие ограничения на создание контента форума, чтобы интеграция могла проверять контент перед попыткой создания или обновления тем.

Настройки, доступ к которым я пытаюсь подтвердить, включают:

min_topic_title_length
max_topic_title_length
min_first_post_length
min_post_length
max_post_length
max_tags_per_topic
max_tag_length
tagging_enabled
create_tag_allowed_groups
tag_topic_allowed_groups

Сначала я проверил /site.json, который доступен и полезен для публичных подсказок о возможностях, но он, по-видимому, не предоставляет эти конкретные настройки ограничений на создание контента.

С ключом API для пользователя-бота без прав администратора следующие запросы вернули 404:

/site_settings.json
/admin/site_settings.json
/admin/site_settings

После предоставления пользователю-боту прав администратора следующие запросы сработали:

/admin/site_settings.json
/admin/site_settings

С использованием заголовков:

Accept: application/json
Api-Key: ...
Api-Username: discussbridge-bot
X-Requested-With: XMLHttpRequest

/site_settings.json по-прежнему возвращал 404.

Мои вопросы:

  1. Является ли /admin/site_settings.json ожидаемым путем API для чтения текущих настроек сайта?
  2. Требуется ли право пользователя-администратора, или существует поддерживаемая область действия API для чтения с гранулярным доступом?
  3. Является ли /site_settings.json устаревшим, зависящим от плагинов или не ожидаемым к существованию?
  4. Для интеграций является ли рекомендуемым паттерном использование ключа диагностики/настройки с правами администратора для чтения настроек, в то время как для обычной работы по синхронизации тем/постов используется ключ с меньшими привилегиями?

Цель не в том, чтобы изменять настройки через API, а только в том, чтобы читать их во время диагностики настройки, чтобы интеграция

2

  1. Это /admin/site_settings.json

  2. Вам нужно быть администратором, за исключением настроек, у которых указано client: true; их можно найти в /site/settings.json

Все настройки, которые вам нужны, за исключением последних двух, можно найти в /site/settings.json.

Но для разрешённых групп механизм работает иначе: если вы запросите /site.json от имени конкретного пользователя, вы сможете проверить значения can_tag_topics и can_create_tags.

  1. Насколько мне известно, /site_settings.json никогда не существовало.

  2. Думаю, что в вашем конкретном случае можно обойтись обычным пользователем, используя подход из пункта 2.

3

Спасибо, @RGJ, это было именно то различие, которого не хватало.

Я проверил пути на своем форуме и могу подтвердить:

/site/settings.json

/site.json

работают с моим текущим глобальным/административным ключом бота.

/site/settings.json предоставляет числовые ограничения авторства, которые мне нужны, включая:

min_topic_title_length
max_topic_title_length
min_first_post_length
min_post_length
max_post_length
max_tags_per_topic
max_tag_length
tagging_enabled

А /site.json, при запросе от имени пользователя бота, предоставляет:

can_tag_topics
can_create_tag

Кажется, это правильный шаблон для диагностики настройки.

Один дополнительный вопрос: я также протестировал детализированный API-ключ, ограниченный для работы с публикацией тем/постов/категорий/тегов:

categories:list
categories:show
posts:edit
posts:list
search:show
tags:list
topics:write
topics:update
topics:read
topics:status

С этим детализированным ключом:

/t/{topic_id}.json работает
/tags.json          работает
/categories.json    работает

но:

/site/settings.json  403
/site.json           403

Я не вижу очевидной детализированной области в интерфейсе администратора, которая позволяла бы доступ к этим двум сайтовым конечным точкам.

Я что-то упускаю в отношении детализированной области или разрешенных URL-адресов для /site/settings.json и /site.json?

Поскольку ключи предназначены для пользователя бота-администратора, каждый ключ обладает правами администратора на уровне пользователя. Детализированный ключ лишь ограничивает, к каким API-конечным точкам он может обращаться.

Если нет, то моя практическая настройка во время тестирования выглядит следующим образом:

  1. текущий глобальный ключ публикации
  2. глобальный ключ диагностики для проверок настройки, читающий настройки сайта
  3. кандидат на детализированный ключ публикации для обычной синхронизации тем/постов/тегов

Если детализированный ключ публикации окажется достаточным для обычной синхронизации, исходный глобальный ключ публикации можно отозвать, оставив:

  1. детализированный ключ публикации для синхронизации в рабочем режиме
  2. глобальный/административный ключ диагностики для проверок настройки

Но это зависит от того, может ли детализированный ключ покрывать все обычные операции публикации, и должны ли /site/settings.json / /site.json оставаться на стороне диагностики.