Discourse Events предоставляет ряд REST-эндпоинтов по адресу /discourse-post-event/..., однако при создании административного API-ключа с областью Granular (подробная) не наблюдается специфической области для Events.
Уже существует область пользовательского API-ключа discourse-calendar:events_calendar для лент подписки на календарь, таких как эндпоинт ICS, поэтому данное предложение касается именно подробных административных/сервер-к-серверу REST API-ключей, а не ключей подписки на календарь.
Сценарий использования
Внешняя интеграция может нуждаться только в запросах к Discourse Events — например, для проверки существования события или получения информации о нём.
В настоящее время, по всей видимости, нет способа выдать административный API-ключ, ограниченный исключительно REST-эндпоинтами Discourse Events. Это означает, что интеграции может потребоваться предоставить доступ к более широкой области API, чем это действительно необходимо.
Было бы полезно, если бы discourse-events регистрировал области подробных API-ключей для своих REST-маршрутов, чтобы интеграции могли следовать принципу минимальных привилегий.
Идеально, если бы эти области могли различать операции, например:
- чтение/запрос событий
- управление событиями
- управление приглашёнными на события
Даже начальная область только для чтения для Events была бы полезна.
В недавнем связанном отчёте также отмечалось, что при попытке использовать область Granular API-ключа не было обнаружено видимых ограничений для эндпоинтов Events.
Существующие маршруты Events сохраняют пространство имён URL /discourse-post-event/... для совместимости, несмотря на то, что сам плагин теперь называется discourse-events, поэтому, на мой взгляд, область не обязательно должна использовать старое имя плагина.
В настоящее время у меня нет достаточно времени, чтобы подготовить PR для этого, но я хотел поднять этот вопрос как запрос на добавление функции, на случай если это будет полезно для других интеграций или будет подходящим изменением с меткой pr-welcome.