Devise/Omniauth failure: How to debug it?

2019-04-20 16:47发布

问题:

After trying to "log in with Google", I'm seeing this error in the logs:

Processing by Users::OmniauthCallbacksController#failure as HTML

I can see all the data from google being sent through the URL (in the logs), including user email and name. So what could go wrong? My callbacks aren't even being executed. I only get redirected to the sign_in page of my site.

And I'm pretty sure everything is configured correctly, because this was working fine some weeks ago. I don't think I changed anything. Facebook login still works fine.

Any ideas on how to debug this failure? There is nothing else in the logs, other than those long URLs full of parameters and values. Only INFO messages. The one posted above is the only one that said something about a failure.

UPDATE

I added a 'failure' method to the controller

def failure
  render :text => params.inspect
end

Which stopped the redirects, and printed this:

{}

The url was this:

/users/auth/google/callback?_method=post&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fud&openid.response_nonce=2012-04-16T12%3A25%3A49Z_v1fNngSQJaHBQ&openid.return_to=http%3A%2F%2Fdev.myapp.me%3A3000%2Fusers%2Fauth%2Fgoogle%2Fcallback%3F_method%3Dpost&openid.assoc_handle=AMlYA9Urw_lYamPphTSdQ9a6DU0Ez0y5RaDDM78qPL7Xgm77nMpJiB85&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle%2Cns.ext1%2Cext1.mode%2Cext1.type.ext5%2Cext1.value.ext5%2Cext1.type.ext8%2Cext1.value.ext8%2Cext1.type.ext2%2Cext1.value.ext2&openid.sig=2FPjo7U1e%2Fde248XpUgjQLduNAM%3D&openid.identity=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DAItOawk1F5U6x_-kJnydjoww5haU41tquh1Zl2c&openid.claimed_id=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DAItOawk1F5U6x_-kJnydjoww5haU41tquh1Zl2c&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ext1.mode=fetch_response&openid.ext1.type.ext5=http%3A%2F%2Faxschema.org%2FnamePerson%2Ffirst&openid.ext1.value.ext5=Some_User&openid.ext1.type.ext8=http%3A%2F%2Faxschema.org%2Fcontact%2Femail&openid.ext1.value.ext8=some_email%40gmail.com&openid.ext1.type.ext2=http%3A%2F%2Faxschema.org%2FnamePerson%2Flast&openid.ext1.value.ext2=Some_User

So the thing is that all the data I need is in the URL, but devise/omniauth is not grabbing it (and apparently that's why it's calling the 'failure' method instead of my callbacks). I don't know if it should be accessible through the 'params' array, or what.

I'm also intrigued about the ?_method=post part, because all the requests to my site are GET requests. Maybe it just means that the request done by omniauth to google was POST.

Any thoughts?

回答1:

To answer the original question about how you debug Omniauth, here's how to enable logging for Omniauth. Add this line to config/initializers/devise.rb just after you define your Omniauth strategies:

OmniAuth.config.logger = Rails.logger if Rails.env.development?

(If you're not using Devise, just Omniauth, then add the code instead to config/initializers/omniauth.rb)

You'll get loads more information from Omniauth in your log file - including the full response from the callback phase.



回答2:

I know this is an old question, but I had this same issue and nothing I found on the net helped. Turns out the issue was caused by how I was using Puma (practices brought over from Thin). I was starting multiple Puma processes on the same machine (Apache reverse proxy) and it appears the call-back from Github was going to a different Puma process than the original authentication request. I took the Puma processes down to one and didn't have the condition again (switched to using Puma workers: puma -w 5, which in turn uses processes that are managed by Puma instead of Apache round robin). This is also why I never stumbled on the issue in development because I don't run a cluster of processes in that environment.



回答3:

I realize that this as an old question and that the person who originally asked it either solved it or moved to some other solution, however, I encountered the same problem, and my quest for solution led me here.

I managed to solve it, so here it is for the next person looking for it.

It turned out to be trivial. This is what I had:

# config/initializers/omniauth.rb
Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, ENV['github_key'], ENV['github_secret']
end

# config/initializers/devise.rb
Devise.setup do |config|
  # ... devise config not related to omniauth ...
  config.omniauth :github, ENV['github_key'], ENV['github_secret']
end

So, I was configuring the omniauth provider in two places, and it was conflicting.

After I removed the config from omniauth.rb, the redirection request from github to /auth/github/callback started being processed by Users::OmniauthCallbacksController#github instead of #failure as was the situation prior to the change.

So dumb error and so little info to work with...



回答4:

Did you recently upgrade your gems? If so, it might be useful to compare omniauth and devise versions with the previous gem versions. It could also be an omniauth/devise dependency that changed.

I am not exactly sure what the problem is in this specific case, but if you want to dig deep in the code, then install the pry-debug gem. It gives you the pry interface with step and next debug commands. Add pry.binding in your code and it will stop execution in the server and bring up the pry interface. For example:

def failure
  binding.pry
  render :text => params.inspect
end