Błąd devise/omniauth: jak to debugować?

Question

Po starając się „zalogować się z Google”, widzę ten błąd w dziennikach:

Processing by Users::OmniauthCallbacksController#failure as HTML 

widzę wszystkie dane z Google są wysyłane za pośrednictwem adresu URL (w dziennikach), w tym użytkownikowi e-mail i nazwisko. Co może pójść nie tak? Moje wywołania zwrotne nie są nawet wykonywane. Zostaję przekierowany tylko na stronę sign_in mojej witryny.

I jestem prawie pewien, że wszystko jest poprawnie skonfigurowane, ponieważ działało to dobrze kilka tygodni temu. Nie sądzę, żebym coś zmieniła. Logowanie na Facebooku nadal działa dobrze.

Jakieś pomysły dotyczące debugowania tego błędu? W dziennikach nie ma nic oprócz długich adresów URL pełnych parametrów i wartości. Tylko komunikaty INFO. Ten zamieszczony powyżej jest jedynym, który powiedział coś o awarii.

UPDATE

dodałem 'porażka' metody kontrolera

def failure 
    render :text => params.inspect 
end 

Który zatrzymał przekierowań i drukowane to:

{} 

adres URL został w ten sposób:

/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 

Chodzi o to, że wszystkie dane, których potrzebuję, znajdują się w adresie URL, ale dev/omniauth go nie chwyta (i widocznie dlatego nazywa się metodę "niepowodzenia" zamiast moich wywołań zwrotnych). Nie wiem, czy powinien być dostępny za pośrednictwem tablicy "params", czy co.

Jestem również zaintrygowany częścią ?_method=post, ponieważ wszystkie żądania do mojej witryny są żądaniami GET. Może to po prostu oznacza, że ​​żądanie wykonane przez omniauth do google było POST.

Jakieś myśli?

Answer 1

Czy niedawno zaktualizowałeś swoje klejnoty? Jeśli tak, warto porównać omniauth i opracować wersje z poprzednimi wersjami gem. Może to być również zależność omniauth/devise, która się zmieniła.

Nie jestem do końca pewien, na czym polega problem w tym konkretnym przypadku, ale jeśli chcesz zagłębić się głęboko w kodzie, zainstaluj klejnot pry-debug. Zapewnia on interfejs podrzędny z poleceniami krokowymi i następnymi debugowania. Dodaj pry.binding w swoim kodzie, a to zatrzyma wykonywanie na serwerze i wyświetli interfejs podrzędny. Na przykład:

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

Answer 2

Wiem, że to stare pytanie, ale miałem ten sam problem i nic, co znalazłem w sieci, nie pomogło. Okazało się, że problem został spowodowany przez to, jak używałem Puma (praktyki przeniesione z Thin). Zaczynałem wiele procesów Puma na tej samej maszynie (odwrotne proxy Apache) i wygląda na to, że oddzwonienie z Githubu przechodziło do innego procesu Puma niż pierwotne żądanie uwierzytelnienia. Zrobiłem procesy Puma w dół do jednego i nie miałem już warunku ponownie (przełączono na używanie robotów Puma: puma -w 5, który z kolei wykorzystuje procesy zarządzane przez Puma zamiast Apache round robin). Właśnie dlatego nigdy nie natknąłem się na tę kwestię w fazie rozwoju, ponieważ nie prowadzę klastra procesów w tym środowisku.

Answer 3

Zdaję sobie sprawę, że jest to stare pytanie i osoba, która pierwotnie poprosiła o rozwiązanie, albo rozwiązała jakieś inne rozwiązanie, napotkałem ten sam problem, a moje poszukiwania rozwiązania doprowadziły mnie tutaj.

Udało mi się go rozwiązać, więc oto jest dla następnej osoby, która go szuka.

Okazało się to banalne. To co miałem:

# 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 

Więc ja konfigurowania omniauth dostawcą w dwóch miejscach, a to było sprzeczne.

Po usunięciu config z omniauth.rb, żądanie przekierowanie z github do /auth/github/callback zaczęto przetwarzane Users::OmniauthCallbacksController#github zamiast #failure jak w sytuacji przed zmianą.

tak głupi błąd i tak mało informacji, aby pracować z ...

Answer 4

Aby odpowiedzieć na pytanie, jak oryginalny debugowania Omniauth, oto jak włączyć rejestrowanie dla Omniauth. Dodaj tę linię do config/initializers/devise.rb tuż po zdefiniować swoje strategie Omniauth:

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

(Jeśli nie używasz opracowania, tylko Omniauth, następnie dodać kod zamiast config/initializers/omniauth.rb)

Dostaniesz mnóstwo więcej informacje z Omniauth w pliku dziennika - w tym pełna odpowiedź z fazy oddzwaniania.