OmniAuth - текущий сеанс не загружен при обратном вызове OpenID - PullRequest
Новая
       6

OmniAuth - текущий сеанс не загружен при обратном вызове OpenID

8 голосов
/ 19 февраля 2011

Я использую OmniAuth с Rails 3.1.4 и пытаюсь разрешить уже аутентифицированным пользователям связывать нескольких поставщиков OpenID с их учетной записью.

Как пользователь, не прошедший проверку подлинности, вход в систему с использованием OpenID работает нормально. Как аутентифицированный пользователь, когда я пытаюсь войти в систему с другим провайдером oid, когда выполняется метод обратного вызова, это выглядит так, будто я ранее не проходил аутентификацию.

Мне кажется, что контроллер запускается до того, как сеансы инициализируются (или сеансы полностью пропускаются).

Что бы это могло быть?

Ответы [ 3 ]

13 голосов
/ 11 марта 2011

Подтверждая решение Андрея Серделюка, у меня работало отключение protect_from_forgery (Ruby 1.8.7, Rails 2.3.11, OmniAuth 0.1.6)

в вашем CallbackController (AuthenticationsController в известной заставке) добавление skip_before_filter :verify_authenticity_token или protect_from_forgery :except => :create вверху работы контроллера!

Поскольку это может быть способом CSRF (Подделка межсайтовых запросов), вы должны проверить подлинность сервера openid, не забудьте настроить проверку сертификата (в инициализаторе): 

# First of all get a ca-bundle.crt file (eg : from your open-source browser package)
require "openid/fetchers"
OpenID.fetcher.ca_file = "#{Rails.root}/config/ca-bundle.crt""

это предотвратит такие предупреждения как: 

WARNING: making https request to https://www.google.com/accounts/o8/id 
without verifying server certificate; no CA path was specified.

Теперь мои сеансы больше не сбрасываются, и я могу добавить несколько аутентификаций openid для моего current_user.

ура

2 голосов
/ 20 февраля 2011

Имейте в виду, что в OmniAuth нет понятия «вход в систему».Он просто проверяет, что пользователь прошел аутентификацию в стороннем приложении, и предоставляет вам информацию, необходимую для реализации собственной системы входа в систему (или интеграции с существующей ).(Есть отличные скринкасты по этой теме; см., Например, часть 1 и часть 2 на Railscasts.)

При этом предполагается, что у вас нетЯ попал в эту общую ловушку и действительно испытываю проблемы с доступом к данным сеанса в вашем обратном вызове.Некоторое базовое тестирование с моей стороны показывает, что сеансы работают, как и ожидалось, в обратном вызове OmniAuth.См. Следующий код по адресу https://github.com/BinaryMuse/so_5049994/compare/master...experiment:

class AuthController < ApplicationController
  def callback
    session[:count] ||= 0
    session[:count] += 1

    @count = session[:count]
    @env   = env['omniauth.auth']
  end
end

После проверки подлинности с помощью различных служб, к которым у меня есть приложения (среди них Facebook и Twitter), я получаю вывод, подобный следующему (см. просмотр файла ): 

OmniAuth Callback

Number of times viewed (session): 5

OmniAuth Hash:

  {"provider"=>"facebook", "uid"=>"1017... (rest of omniauth hash here)
0 голосов
/ 14 декабря 2017

Что касается меня, я должен реализовать приложение с помощью Intuit и столкнулся с той же проблемой.Что для меня исправило, так это не удаление защиты от подделки или пропуск проверки authenticity_token, а проверка того, что страница, на которой я отправляю форму авторизации локально, имеет тот же хост, что и URL перенаправления.У меня было 127.0.0.1:3000, но redirect_url был localhost:3000.

...