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

Question

Después de tratar de "iniciar sesión con Google", que estoy viendo este error en los registros:

Processing by Users::OmniauthCallbacksController#failure as HTML 

puedo ver todos los datos de Google de ser enviado a través de la dirección URL (en los registros), incluyendo usuario correo electrónico y nombre Entonces, ¿qué podría salir mal? Mis devoluciones de llamada ni siquiera se están ejecutando. Solo me redirigen 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 algunas semanas. No creo que haya cambiado nada. El inicio de sesión en Facebook sigue funcionando bien.

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

ACTUALIZACIÓN

I añadió un método 'fracaso' al controlador

def failure 
    render :text => params.inspect 
end 

que paró las redirecciones, y se imprime esta:

{} 

La url era la siguiente:

/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 cuestión es que todos los datos que necesito están en la URL, pero idee/omniauth no la está agarrando (y aparentemente es por eso que está llamando al método de "falla" en lugar de llamar). No sé si debería ser accesible a través de la matriz 'params', o qué.

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

¿Alguna idea?

Answer 1

¿Recientemente ha actualizado sus gemas? Si es así, podría ser útil comparar omniauth y diseñar versiones con las versiones de gema anteriores. También podría ser una dependencia omniauth/idear que cambió.

No estoy seguro de cuál es el problema en este caso específico, pero si desea profundizar en el código, instale la gema pry-debug. Le proporciona la interfaz de palanca con los pasos y los próximos comandos de depuración. Agregue pry.binding en su código y se detendrá la ejecución en el servidor y aparecerá la interfaz de palanca. Por ejemplo:

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

Answer 2

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

Answer 3

Me doy cuenta de que esta es una pregunta antigua y que la persona que originalmente la solicitó la resolvió o cambió a otra solución, sin embargo, me encontré con el mismo problema y mi búsqueda de soluciones me llevó hasta aquí.

Pude resolverlo, así que aquí está para la siguiente persona que lo busque.

Resultó ser trivial. Esto es lo que 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 

Por lo tanto, yo estaba Configuración del proveedor OmniAuth en dos lugares, y fue conflictiva.

Después Quité el config de omniauth.rb, la demanda de redirección de github a /auth/github/callback iniciadas que está siendo procesado por Users::OmniauthCallbacksController#github en lugar de #failure como era la situación antes del cambio.

error tan tonto y tan poca información para trabajar con ...

Answer 4

Para responder a la pregunta original sobre cómo depurar OmniAuth, aquí es cómo habilitar el registro de OmniAuth. Añadir esta línea a config/initializers/devise.rb justo después de definir sus estrategias OmniAuth:

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

(Si no se está usando Diseñar, simplemente OmniAuth, a continuación, añadir el código en lugar de config/initializers/omniauth.rb)

Usted obtendrá un montón más información de Omniauth en su archivo de registro, incluida la respuesta completa de la fase de devolución de llamada.