Omniauth: как установить данные поставщика аутентификации во время выполнения

У меня есть приложение rails, доступное из двух доменов. Facebook требует от меня зарегистрировать приложение facebook для каждого из этих доменов и дает мне учетные данные для каждого. С Omniauth я могу указать только один набор учетных данных, который устанавливается при запуске приложения. Однако мне нужно будет предоставить FB разные учетные данные в зависимости от хоста запроса.

Здесь есть 2 проблемы:

  1. Как я могу изменить учетные данные Omniauth для facebook во время выполнения?
  2. Как я могу перехватить вызов на facebook, проверить домен и соответствующим образом установить учетные данные? Предварительный фильтр не будет работать, так как Omniauth использует Rack Middleware.

Любые предложения высоко ценятся!


ruby-on-rails middleware omniauth rack
person Nico    schedule 15.02.2011    source источник
comment
Хорошо, я нашел инструкции по этому поводу здесь: github.com/intridea/omniauth/wiki /Dynamic-Providers Однако они мне не подходят. Omniauth идет прямо к провайдеру, даже если я настроил маршрут для перехвата вызова 'provider/auth'... Я использую Rails 2.3.5 с Omniauth 0.1.6.   -  person Nico    schedule 16.02.2011
comment
Хорошо, я обновил гем до версии 0.2.0.beta4, и маршрут теперь работает, но даже если я установил переменные среды на правильные учетные данные, я получаю ошибку аутентификации. URL-адрес авторизации для facebook выглядит точно так же, как и при настройке учетных данных вручную в конфиге. Кстати, вары теперь называются (client_id и client_secret, а не Consumer_key и Consumer_secret, как написано в вики).   -  person Nico    schedule 16.02.2011
comment
Я решил это сам сейчас. Проблема заключалась в том, что стратегия fb обращается к fb второй раз, чтобы получить токен доступа. В этом втором вызове использовались неправильные учетные данные (те, которые установлены в инициализаторе). Поэтому мне пришлось исправить стратегию OAuth2, чтобы она снова вызывала приложение rails, чтобы установить учетные данные времени выполнения для этого второго вызова. В обратном вызове, который обычно обрабатывает только форму ответа Omniauth, я устанавливаю учетные данные и возвращаю 404, если только не присутствует request.env[omniauth.auth]. Это прекрасно работает, но имеет некоторые побочные эффекты для приложений без динамических провайдеров.   -  person Nico    schedule 17.02.2011
comment
Теперь проблема заключается в том, что даже если приложение не хочет устанавливать учетные данные во время выполнения, оно должно добавить условие к обратному вызову, например, если request.env[omniauth.auth], чтобы избежать выполнения кода обратного вызова, когда он звонил первый раз. Решение, вероятно, состоит в том, чтобы добавить параметр в построитель Omniauth, например: dynamic_provider, и вызывать приложение только в том случае, если он установлен.   -  person Nico    schedule 17.02.2011
comment
Я вижу, вы используете Rails 2.3.5 и Omniauth 0.1.6. Я не могу заставить их работать вместе, так как для рельсов 2.3.5 требуется Rack 1.0.1, а для Omniauth требуется Rack 1.1. Любая помощь очень ценится. Павел   -  person Paul    schedule 12.06.2011
comment
Привет, Пол, я использую Rack 1.2.1 и удалил зависимость Rack 1.0.1 от Rails (я ее продал). Я также исправил Rack в lib/rack/utils.rb: я изменил определение ESCAPE_HTML_PATTERN на ESCAPE_HTML_PATTERN = Regexp.union(*ESCAPE_HTML.keys). Дайте мне знать, если это поможет вам.   -  person Nico    schedule 15.06.2011
comment
@Nico - Если вы хотите резюмировать решение как свой собственный ответ, я удалю свой ответ. (См. meta.stackexchange.com/questions/90263. / за разъяснения, почему это полезно.) Спасибо!   -  person DreadPirateShawn    schedule 09.10.2013

Ответы (2)


arrow_upward
1
arrow_downward

Копирование ответа из комментариев, чтобы убрать этот вопрос из фильтра «Неотвеченные»:

Я решил это сам сейчас. Проблема заключалась в том, что стратегия fb обращается к fb второй раз, чтобы получить токен доступа. В этом втором вызове использовались неправильные учетные данные (те, которые установлены в инициализаторе). Поэтому мне пришлось исправить стратегию OAuth2, чтобы она снова вызывала приложение rails, чтобы установить учетные данные времени выполнения для этого второго вызова. В обратном вызове, который обычно обрабатывает только форму ответа Omniauth, я устанавливаю учетные данные и возвращаю 404, если только не присутствует request.env[omniauth.auth]. Это прекрасно работает, но имеет некоторые побочные эффекты для приложений без динамических провайдеров.

Проблема сейчас в том, что даже если приложение не хочет устанавливать учетные данные во время выполнения, оно должно добавить условие к обратному вызову, например, если request.env[omniauth.auth], чтобы избежать выполнения кода обратного вызова, когда он звонил первый раз. Решение, вероятно, состоит в том, чтобы добавить параметр в конструктор Omniauth, например :dynamic_provider, и вызывать приложение только в том случае, если он установлен.

~ ответ на Нико

person DreadPirateShawn    schedule 08.10.2013

arrow_upward
1
arrow_downward

Этот вопрос довольно старый, но все еще актуальный. В настоящее время также можно динамически устанавливать сведения о поставщике на этапе настройки OmniAuth.

Например:

Rails.application.config.middleware.use do
  provider :example, 
    setup: ->(env) do
      env['omniauth.strategy'].options[:foo] = env['rack.session']['foo']
      env['omniauth.strategy'].options[:client_options][:site] = Something.dynamic('param')
  end
end

Источник: https://github.com/omniauth/omniauth/wiki/Dynamic-Providers< /а>

person Petrus Repo    schedule 18.06.2021