Некоторые эндпоинты не требуют никакой аутентификации, но для доступа практически ко всему остальному требуется авторизация. Чтобы получить авторизацию, необходимо создать API-ключ в панели администратора.
Это жаль, так как существует множество законных способов использования API, которыми могли бы воспользоваться обычные пользователи, а не только администраторы.
Например, пользователь мог бы настроить ежемесячную задачу cron для загрузки своего preferences.json вместо того, чтобы нажимать кнопку «Скачать» в разделе «Настройки» (Backup/export/import Preferences).
Я утверждаю, что необходимо внести изменения в исходный код, чтобы вскоре пользователи по всему миру получили возможность обращаться к API локального Discourse, который они используют, для получения своих личных данных и т. д.
Однако без поддержки со стороны администраторов и утверждённой конечной точки в настройках сайта для ключей API пользователей «обычные пользователи» всё ещё не могут просто сгенерировать свои собственные ключи API.
Этот ответ неверен. Любой пользователь может сгенерировать пользовательский API-ключ, если генерация таких ключей включена для уровня доверия пользователя. Если вы не укажете перенаправление в теле запроса, в браузере будет отображён ответ в кодировке base64, содержащий ключ.
Смотрите эту тему для получения скрипта, демонстрирующего, как это делается.
Я думаю о стандартном случае, когда человек А установил Discourse, а человек Б — обычный пользователь на сервере А, причём А не менял никаких настроек администратора. Может ли Б всё же что-то сделать с помощью API?
Генерация ключей API пользователя по умолчанию включена для всех пользователей, и всё, что вы можете сделать через веб-интерфейс, доступно и через API, поскольку веб-интерфейс является лишь фронтендом для API.
Лично я использую его в расширении для Chrome, которое ведёт подсчёт всех моих непрочитанных уведомлений по всем экземплярам, где у меня есть учётные записи, за несколькими исключениями.
Если у пользователя уже есть учётная запись на экземпляре Discourse, он должен иметь возможность использовать ту же куки-аутентификацию из браузера для любых API-запросов, не связанных с браузером.
