Fallo de Devise / Omniauth: ¿Cómo depurarlo?

Después de intentar “iniciar sesión con Google”, veo este error en los registros:

Processing by Users::OmniauthCallbacksController#failure as HTML 

Puedo ver todos los datos de google enviados a través de la URL (en los registros), incluido el correo electrónico y el nombre del usuario. Entonces, ¿qué podría salir mal? Mis devoluciones de llamada ni siquiera se están ejecutando. Solo me redireccionan a la página de inicio de sesión de mi sitio.

Y estoy bastante seguro de que todo está configurado correctamente, porque esto funcionó bien hace unas semanas. No creo que haya cambiado nada. El inicio de sesión en Facebook todavía funciona bien.

¿Alguna idea sobre cómo depurar este fallo? No hay nada más en los registros, aparte de esas largas URL llenas de parámetros y valores. Solo mensajes INFO. El publicado anteriormente es el único que dijo algo acerca de un fracaso.

ACTUALIZAR

Agregué un método de ‘falla’ al controlador

 def failure render :text => params.inspect end 

Lo que detuvo las redirecciones, e imprimió esto:

 {} 

La url era esta:

 /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 

Entonces, la cosa es que todos los datos que necesito están en la URL, pero el dispositivo / omniauth no lo está capturando (y aparentemente es por eso que se llama el método de “falla” en lugar de mis devoluciones de llamada). No sé si debería ser accesible a través de la matriz ‘params’, o qué.

También estoy intrigado por la parte ?_method=post , porque todas las solicitudes a mi sitio son solicitudes GET. Tal vez solo significa que la solicitud realizada por omniauth a google fue POST.

¿Alguna idea?

Para responder a la pregunta original acerca de cómo depurar Omniauth, aquí se explica cómo habilitar el registro para Omniauth. Agregue esta línea a config/initializers/devise.rb justo después de definir sus estrategias de Omniauth:

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

(Si no está utilizando Devise, solo Omniauth, agregue el código en su lugar a config/initializers/omniauth.rb )

Obtendrá mucha más información de Omniauth en su archivo de registro, incluida la respuesta completa de la fase de callback.

Sé que esta es una pregunta antigua, pero tuve el mismo problema y nada de lo que encontré en la red me ayudó. Resulta que el problema fue causado por la forma en que estaba usando Puma (prácticas traídas de Thin). Estaba iniciando varios procesos de Puma en la misma máquina (proxy inverso de Apache) y parece que la callback de Github iba a un proceso de Puma diferente al de la solicitud de autenticación original. Tomé los procesos de Puma a uno y no volví a tener la condición (cambié a usar trabajadores de Puma: puma -w 5 , que a su vez usa procesos que son administrados por Puma en lugar de Apache round robin). Esta es la razón por la que nunca me topé con el problema en el desarrollo porque no ejecuto un grupo de procesos en ese entorno.

Me doy cuenta de que esto era una pregunta antigua y que la persona que la formuló originalmente la resolvió o se trasladó a alguna otra solución; sin embargo, encontré el mismo problema y mi búsqueda de una solución me condujo hasta aquí.

Me las arreglé para resolverlo, así que aquí está para la siguiente persona que lo busque.

Resultó ser trivial. Esto es lo que yo tenía:

 # 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 

Entonces, estaba configurando el proveedor de omniauth en dos lugares, y fue conflictivo.

Después de que eliminé la configuración de omniauth.rb, la solicitud de redirección de github a /auth/github/callback comenzó a ser procesada por Users::OmniauthCallbacksController#github lugar de #failure como era la situación anterior al cambio.

Error tan tonto y tan poca información para trabajar con …

¿Has actualizado recientemente tus gems? Si es así, podría ser útil comparar omniauth e idear versiones con las versiones anteriores de gems. También podría ser una dependencia omniauth / devise que cambió.

No estoy exactamente seguro de cuál es el problema en este caso específico, pero si desea profundizar en el código, instale la gem de depuración. Te da la interfaz de palanca con los comandos de depuración paso y siguiente. Agregue pry.binding en su código, detendrá la ejecución en el servidor y abrirá la interfaz de palanca. Por ejemplo:

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