У меня возникла проблема с внедрением Discourse на наш интранет-сайт.
В документации по API указано, что для аутентификации и получения доступа к ленте в запросе к Discourse необходимо использовать заголовки «API-Key» и «Api-Username». Однако при предварительной проверке (Pre-flight) сообщается, что разрешёнными значениями являются «User-API-Key» и «User-Api-Client-Id».
При вызове не через браузер всё работает как ожидается. Но при вызове через браузер сервер заявляет, что требуются заголовки «User-API-Key» и «User-Api-Client-Id».
Я проверил базовое подключение через Postman, и оно работает в соответствии с документацией по Discourse.
Если мы передаём заголовки согласно документации, браузер блокирует запрос из-за предварительной проверки и возникает ошибка CORS (Access-Control-Allow-Headers).
Если же мы передаём заголовки, которые принимает сервер, мы получаем ошибку «не авторизован», поскольку приложение ожидает значения с другими именами.
Я пробовал добавлять заголовки в конфигурацию Docker, но, похоже, это не применяется. В конфигурации включён CORS и указан источник «*».
У нас есть две разные системы аутентификации API, что может вызывать путаницу.
Они предназначены для «административного API», описание которого доступно на docs.discourse.org. Этот API не предназначен для использования из JavaScript-клиентов.
Эти параметры относятся к спецификации «User API», которую можно использовать из JavaScript-клиента (и, следовательно, она поддерживает CORS). Подробнее об этом можно узнать здесь: User API keys specification
@david Я использую SSO и хочу разлогинивать пользователя из Discourse, когда он выходит из приложения. Сейчас я использую «Admin API» для получения ID пользователя через /users/by-external/${id}.json, но получаю ошибки CORS. Я не хочу включать «User API» для всех пользователей только для этого процесса выхода. Что вы посоветуете?
Что отправляет запрос к административному API? JavaScript в вашем клиентском приложении?
Включать административный API в клиентское приложение на JavaScript не следует, так как это означает, что любой пользователь клиента может получить административный доступ к вашему сайту.
Да, в моём приложении используется JavaScript. Я понял. Так какой же тогда альтернативный вариант? Могу ли я создать один «API пользователя» для одного пользователя и использовать его для выполнения вызовов от имени всех пользователей?
Если вы используете пользовательский API, делайте это для каждого пользователя отдельно. Не следует обмениваться ключами.
Однако наиболее распространённым подходом здесь является обработка этого на серверной стороне вашего приложения. Ваш сервер может отправлять запросы, используя административные ключи API, без проблем с CORS и с меньшими рисками для безопасности (при условии безопасной реализации).
Привет, @david, я попытался реализовать решение на бэкенде, но при вызове https://example.com/users/by-external/{EXTERNAL_USER_ID}.json?api_key={DISCOURSE_API_KEY}&api_username=system получаю в ответ HTML-страницу входа (предполагаю, что происходит перенаправление туда). У меня включена настройка «Требуется вход», и когда я её отключаю, получаю правильный JSON-ответ. Я хочу оставить эту настройку включённой — есть какие-то идеи, что происходит?
