Пропустить «Авторизовать доступ приложения»

Разработка
1

Мы используем Discourse как инструмент для совместной работы, а для поиска документов у нас есть другое приложение. Мы хотели бы интегрировать комментарии к документам в Discourse. Оба приложения используют внешнего провайдера SSO/OAuth в нашей инфраструктуре.

Для связи двух приложений мы используем ключ API пользователя. Это работает, но нам приходится нажимать на форму «Авторизовать доступ приложения», которую мы хотели бы избежать, так как мы находимся в доверенной среде с поддержкой OAuth.

Есть ли способ избежать этого шага «авторизации» или обойти его и сразу перейти к созданию ключа API пользователя, чтобы эта страница не отображалась и пользователям не приходилось выполнять этот дополнительный шаг? Можно ли указать какой-либо параметр в запросе, чтобы обойти этот шаг?

Мы попробовали сначала вызвать UserApiKeysController.create (вместо UserApiKeysController.new), но получили ошибку CSRF. Тогда мы попробовали пропустить проверку токена следующим образом:

class UserApiKeysController < ApplicationController
  skip_before_action :verify_authenticity_token

Но это тоже не сработало.

Не видите ли вы другого способа решить эту задачу?

Заранее спасибо.

2

Добро пожаловать, Бруно, рады, что вы с нами :slight_smile: Возможно, @david или @blake смогут предложить какие-то идеи по этому поводу.

3

Могу точно сказать, что это не правильный подход. Вы уже используете плагин или взаимодействуете только через HTTP?

Если вы используете плагин, то в большинстве случаев вам не следует взаимодействовать с экземплярами app/controllers/.

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

User API предназначен для клиент-серверного взаимодействия, где нет возможности обеспечить целостность кода на стороне клиента.

4

Да, мы планируем разработать плагин для Discourse, и наше JS-приложение будет взаимодействовать исключительно через HTTP-запросы.
Мы хотели бы избежать необходимости разрабатывать сервер-серверное взаимодействие (например, с использованием API-ключа администратора), чтобы минимизировать связанность компонентов.

Я понимаю, что в идеале мы не должны вмешиваться в контроллеры Discourse, и в то же время существует множество методов, которые, по-видимому, предназначены для переопределения (шаблонный метод и другие точки расширения). Судя по тому, что мы видели до сих пор, многие плагины делают именно это.

Так каков же правильный путь?

5

Если вы разрабатываете плагин, создавайте новые маршруты в контроллере, подключённом к плагину, который напрямую выполняет необходимые задачи. Все эти маршруты могут использовать общий before_action, устанавливающий заголовки ответа Access-Control-Allow-{Origin, Headers, Credentials} (возвращайте заголовок запроса Origin, если он есть в списке доменов, на которых должно работать ваше приложение).

Таким образом, ваш JS-код сможет просто вызывать fetch(..., { credentials: "include", ...}) без какого-либо API-ключа.

6

Спасибо @riking, это работает нормально, когда в браузере уже есть открытая сессия на Discourse.

Мы можем инициировать новую сессию вручную, просто вызвав http://discourse_site/login, так как у нас установлено SiteSetting.enable_local_logins = false и используется только один механизм аутентификации через OAuth. Браузер следует перенаправлениям нашего провайдера OAuth, а затем перенаправляет на Discourse. Именно это происходило «под капотом» при вызове /user-api-key/new.

Как мы могли бы программно инициировать новую сессию в Discourse из приложения, если её нет?