omniauth-browserid icon indicating copy to clipboard operation
omniauth-browserid copied to clipboard

Including browser_id strategy breaks /auth/failure callback

Open mcoms opened this issue 12 years ago • 7 comments

In a rails app, adding provider :browser_id to the bottom of my initialiser block causes all strategy failures to be detected as browser_id failures and causes a redirect loop at /auth/failure.

Steps to reproduce:

A rails app with some strategies and an initializer:

# Gemfile
gem 'omniauth'
gem 'omniauth-openid'
gem 'omniauth-browserid'
gem 'omniauth-identity'
# config/initializers/omniauth.rb
Rails.application.config.middleware.use OmniAuth::Builder do
  provider :openid
  provider :open_id, :name => 'google', :identifier => 'https://www.google.com/accounts/o8/id'
  provider :identity, :fields => [:email]
  provider :browser_id
end

Comment browser_id from the initializer and visit /auth/google. Cause an error by failing authourization on the client. Note the redirect goes to /auth/failure?message=invalid_credentials&strategy=google which is the expected behaviour.

Uncomment browser_id and visit /auth/google. Cause an error by failing authourization on the client. Note the redirect goes to /auth/failure?message=invalid_credentials&strategy=browser_id and forms a redirect loop. Unexpected behaviour.

A faster way to test is to visit /auth/identity and submit a blank form, which will also correctly trigger a failure. This happens with all the strategies listed here, unless browser_id is removed.

Other than that, it works great :)

mcoms avatar Oct 10 '12 00:10 mcoms

This is still a thing, just encountered the same issue

skorfmann avatar Mar 15 '13 04:03 skorfmann

I'm encountering this one as well, has anyone found a workaround for it at all?

glsignal avatar Apr 17 '13 11:04 glsignal

No, haven't looked further into it yet. But I will probably do it the next couple of days, as we're actually going to implement it.

skorfmann avatar Apr 17 '13 11:04 skorfmann

Ah okay. Well from my (tired, quick) glance at the strategy, I'm not entirely certain why the other_phase method is being hit (or what it actually does), any ideas?

glsignal avatar Apr 17 '13 11:04 glsignal

At any rate, there's a hacky workaround by specifying a failure route which doesn't match "#{path_prefix}/failure" (lib/omniauth/strategies/browser_id.rb:24) in the browser_id provider configuration

#!config/initializers/omniauth.rb
Rails.application.config.middleware.use OmniAuth::Builder do
    ...
    provider :browser_id, :failure_path => '/failure'
    ...
end

and matching both /auth/failure and /failure to some controller action.

I feel bad for coming up with such a thing, quite frankly, but desperate times...

glsignal avatar Apr 17 '13 11:04 glsignal

Well, better than nothing :) Thanks for sharing!

skorfmann avatar Apr 17 '13 12:04 skorfmann

No worries! Keen to see a solution to this eventually, might look into it myself if I come across any free time.

glsignal avatar Apr 17 '13 12:04 glsignal