Errore Devise/Omniauth: come eseguirne il debug?

Question

Dopo aver cercato di "login con Google", sto vedendo questo errore nei log:

Processing by Users::OmniauthCallbacksController#failure as HTML 

posso vedere tutti i dati da parte di Google di essere inviato tramite l'URL (nei log), tra cui utenti email e nome. Quindi cosa potrebbe andare storto? Le mie callback non vengono nemmeno eseguite. Ho solo reindirizzato alla pagina sign_in del mio sito.

E sono abbastanza sicuro che tutto sia configurato correttamente, perché funzionava bene alcune settimane fa. Non penso di aver cambiato nulla. Login di Facebook funziona ancora bene.

Qualche idea su come eseguire il debug di questo errore? Non c'è nient'altro nei log, oltre a quegli URL lunghi pieni di parametri e valori. Solo messaggi INFO. Quello pubblicato sopra è l'unico che ha detto qualcosa su un fallimento.

UPDATE

ho aggiunto un metodo di 'fallimento' al controller

def failure 
    render :text => params.inspect 
end 

che si è fermato il redirect, e stampate questo:

{} 

L'url è stato questo:

/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 

Quindi il fatto è che tutti i dati di cui ho bisogno sono nell'URL, ma idea/omniauth non lo sta afferrando (e apparentemente è per questo che chiama il metodo 'failure' invece dei miei callback). Non so se dovrebbe essere accessibile attraverso l'array 'params' o cosa.

Sono anche incuriosito della parte ?_method=post, perché tutte le richieste al mio sito sono richieste GET. Forse significa solo che la richiesta fatta da omniauth a google è stata POST.

Qualche idea?

Answer 1

Recentemente hai aggiornato le tue gemme? Se è così, potrebbe essere utile confrontare le versioni omniauth e escogitare con le precedenti versioni gem. Potrebbe anche essere una dipendenza da omniauth/devise che è cambiata.

Non sono esattamente sicuro di quale sia il problema in questo caso specifico, ma se si desidera approfondire il codice, installare la gemma pry-debug. Ti dà l'interfaccia di leva con i comandi passo passo e successivo. Aggiungi pry.binding nel codice e interromperà l'esecuzione nel server e visualizzerà l'interfaccia di leva. Ad esempio:

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

Answer 2

So che questa è una vecchia domanda, ma ho avuto lo stesso problema e non ho trovato nulla di utile in rete. Risulta che il problema è stato causato da come stavo usando Puma (pratiche portate da Thin). Stavo avviando più processi Puma sulla stessa macchina (proxy inverso Apache) e sembra che il richiamo di Github stia andando a un processo Puma diverso rispetto alla richiesta di autenticazione originale. Ho portato i processi Puma a uno solo e non ho più avuto il problema (passato a utilizzare gli addetti di Puma: puma -w 5, che a sua volta utilizza processi gestiti da Puma invece di Apache round robin). Questo è anche il motivo per cui non mi sono mai imbattuto nel problema dello sviluppo perché non eseguo un cluster di processi in quell'ambiente.

Answer 3

Mi rendo conto che si tratta di una vecchia domanda e che la persona che inizialmente lo ha chiesto o risolto o spostato in un'altra soluzione, tuttavia, ho riscontrato lo stesso problema, e la mia ricerca di soluzione mi ha portato qui.

sono riuscito a risolverlo, così qui è per la prossima persona in cerca di esso.

si è rivelato essere banale. Questo è quello che avevo:

# 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 

Così, mi è stato Configurazione del provider omniauth in due punti, ed è stato in conflitto.

Dopo aver rimosso la configurazione dal omniauth.rb, la richiesta reindirizzamento da github a /auth/github/callback iniziate in lavorazione da Users::OmniauthCallbacksController#github anziché #failure come era la situazione prima della modifica.

errore così stupido e così poco informazioni per lavorare con ...

Answer 4

Per rispondere alla domanda iniziale su come si esegue il debug Omniauth, ecco come attivare la registrazione per Omniauth. Aggiungere questa riga al config/initializers/devise.rb solo dopo aver definito le strategie di Omniauth:

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

(Se non si sta usando Devise, proprio Omniauth, quindi aggiungere il codice invece config/initializers/omniauth.rb)

Si otterrà più carichi informazioni da Omniauth nel tuo file di log, inclusa la risposta completa dalla fase di callback.