В SPA нет собственной системы управления пользователями, я хочу использовать для этого Discourse (так как у нас нет другой пользовательской информации, требующей отдельной системы управления пользователями).
Однако я хочу отображать в SPA текущего вошедшего в систему пользователя из Discourse, а также виджет непрочитанных тем (которые специфичны для пользователя), например, поэтому мне нужно загружать данные через API из Discourse.
Что я пробовал:
Использовать путь SSO Discourse, который затем перенаправляет обратно в мой SPA. Это нормально: я получаю адрес электронной почты текущего пользователя, внешний идентификатор и так далее, но ничего, с помощью чего я мог бы выполнить запрос (токен / ключ).
Экспериментировать с настройками cookie, чтобы иметь возможность использовать cookie Discourse для выполнения запроса (безуспешно).
Я читал о пользовательском API-ключе по адресу User API keys specification, но мне кажется странным просить пользователя разрешить приложению, которое находится на том же сайте, доступ к его учётной записи Discourse.
Есть ли какой-либо способ достичь желаемого поведения?
Используйте DiscourseConnect («SSO для Discourse»), как описано, чтобы получить имя пользователя текущего пользователя.
Создайте ключ API с необходимыми областями доступа и доступом ко всем пользователям.
Очевидно, что нельзя передавать этот ключ веб-приложению на стороне клиента, не подвергая сайт риску, поэтому вам потребуется проксировать запросы от веб-приложения через бэкенд этого приложения к вашему экземпляру Discourse. (И вам нужно будет валидировать, что имя пользователя легитимно, на стороне бэкенда — я не изучал DiscourseConnect, но, presumably, существует способ сделать это.)
(PS: Рекомендую использовать ‘example.com’ для вашего примера домена. Кто-то может купить тот, на который вы дали ссылку, и настроить спам, вредоносное ПО или что-то ещё, тогда как example.[com|org|net] официально зарезервированы (Special-Use Domain Names).)
При перенаправлении пользователя через SSO Middleware создаёт простого пользователя с именем, электронной почтой и массивом токенов, генерирует токен и возвращает его в SPA.
Middleware проксирует запросы к Discourse, используя универсальный API-ключ пользователя, и проверяет «сессионный токен» (чтобы определить, какой это пользователь), а также выполняет другую необходимую проверку безопасности.
Чтобы пользователь оставался в системе, я буду использовать cookie или локальное хранилище и синхронизировать выход через прямой вариант выхода из Discourse.
Это работает, но я всё ещё считаю, что должно быть лучшее решение, чем использование административного API-токена в сочетании с именем пользователя. Это ломается, если какой-то администратор изменит имя пользователя… Мне бы хотелось использовать хеш-идентификатор или что-то подобное… Но это я изменить не могу, так что буду жить с этим
