Na stronie https://code.google.com/apis/console zarejestrowałem aplikację, skonfigurowałem wygenerowany identyfikator klienta: i klucz tajny klienta w mojej aplikacji i próbowałem zalogować się w Google. Niestety dostałem komunikat o błędzie:

Error: redirect_uri_mismatch
The redirect URI in the request: http://127.0.0.1:3000/auth/google_oauth2/callback did not match a registered redirect URI

scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email
response_type=code
redirect_uri=http://127.0.0.1:3000/auth/google_oauth2/callback
access_type=offline
approval_prompt=force
client_id=generated_id

Co oznacza ten komunikat i jak mogę go naprawić? Używam klejnotu omniauth-google-oauth2 .

Identyfikator URI przekierowania (do którego zwracana jest odpowiedź) musi zostać zarejestrowany w konsoli API, a błąd wskazuje, że tego nie zrobiłeś lub nie zrobiłeś tego poprawnie.

Przejdź do konsoli swojego projektu i zajrzyj do API Access. Powinieneś zobaczyć swój client ID& client secrettam, wraz z listą przekierowań URI. Jeśli żądanego identyfikatora URI nie ma na liście, kliknij edytuj ustawienia i dodaj identyfikator URI do listy.

EDYCJA: (od wysoko ocenionego komentarza poniżej) Pamiętaj, że aktualizacja konsoli Google API i obecna zmiana może zająć trochę czasu. Zasadniczo tylko kilka minut, ale czasem wydaje się dłuższy.

W moim przypadku był to wwwi non-wwwadres URL. Rzeczywista witryna miała wwwadres URL, a identyfikatory URI autoryzowanego przekierowania w Google Developer Console miały non-wwwadres URL. W związku z tym wystąpił niedopasowanie w przekierowanym URI. Rozwiązałem go, aktualizując Authorized Redirect URIsw Google Developer Console do wwwadresu URL.

Inne typowe niedopasowania URI to:

• Używanie http://w identyfikatorach URI autoryzowanych przekierowań oraz https://jako rzeczywisty adres URL lub odwrotnie
• Używanie końcowego ukośnika ( http://example.com/) w autoryzowanych identyfikatorach URI przekierowania i nieużywanie końcowego ukośnika ( http://example.com) jako rzeczywistego adresu URL lub odwrotnie

Oto zrzuty ekranu krok po kroku z konsoli programisty Google, aby pomóc osobom, które mają trudności ze zlokalizowaniem strony konsoli programisty, aby zaktualizować identyfikatory URI przekierowania.

1. Wejdź na https://console.developers.google.com

2. Wybierz swój projekt

3. Kliknij ikonę menu

4. Kliknij API Managermenu

5. Kliknij Credentialsmenu. A poniżej OAuth 2.0 Client IDsznajdziesz swoją nazwę klienta. W moim przypadku tak jest Web Client 1. Kliknij na niego, a pojawi się wyskakujące okienko, w którym możesz edytować Autoryzowane pochodzenie JavaScript i URI autoryzowanych przekierowań .

Oto artykuł Google na temat tworzenia identyfikatora projektu i klienta .

Jeśli używasz przycisku javascript Google+ , musisz użyć postmessagezamiast rzeczywistego identyfikatora URI. Rozpracowanie tego zajęło mi prawie cały dzień, ponieważ dokumenty Google nie podają tego jasno z jakiegoś powodu.

W każdym przepływie, w którym pobrałeś kod autoryzacji po stronie klienta, taki jak GoogleAuth.grantOfflineAccess()API , a teraz chcesz przekazać kod do serwera, wykorzystać go i przechowywać tokeny dostępu i odświeżania, musisz użyć literału postmessagezamiast redirect_uri.

Na przykład w oparciu o fragment kodu w dokumencie Ruby :

client_secrets = Google::APIClient::ClientSecrets.load('client_secrets.json')
auth_client = client_secrets.to_authorization
auth_client.update!(
  :scope => 'profile https://www.googleapis.com/auth/drive.metadata.readonly',
  :redirect_uri => 'postmessage' # <---- HERE
)

# Inject user's auth_code here:
auth_client.code = "4/lRCuOXzLMIzqrG4XU9RmWw8k1n3jvUgsI790Hk1s3FI"
tokens = auth_client.fetch_access_token!
# { "access_token"=>..., "expires_in"=>3587, "id_token"=>..., "refresh_token"=>..., "token_type"=>"Bearer"}

Jedyną dokumentacją Google, o której można nawet wspomnieć, postmessagejest ten stary dokument logowania do Google+ . Oto zrzut ekranu i link do archiwum, ponieważ G + się zamyka i ten link prawdopodobnie zniknie:

Jest absolutnie niewybaczalne, że strona dokumentu dla dostępu offline nie wspomina o tym. #FacePalm

W mojej aplikacji internetowej poprawiłem swój błąd pisząc

instead of : http://localhost:11472/authorize/
type :      http://localhost/authorize/

Upewnij się, że sprawdziłeś protokół „http: //” lub „https: //” jako protokół kontroli Google. Lepiej dodać oba adresy URL do listy.

Wydaje się to dość dziwne i denerwujące, że nie ma „jednego” rozwiązania. dla mnie http: // localhost: 8000 nie działało, ale http: // localhost: 8000 / działało.

Po zarejestrowaniu aplikacji na https://code.google.com/apis/console i utworzeniu identyfikatora klienta masz szansę określić co najmniej jeden identyfikator URI przekierowania. Wartość redirect_uriparametru w twoim identyfikatorze URI uwierzytelniania musi dokładnie odpowiadać jednemu z nich.

Ta odpowiedź jest taka sama, jak odpowiedzieć na to Mike'a , a odpowiedź Jeffa , oba zestawy redirect_urido postmessagepo stronie klienta. Chcę dodać więcej o stronie serwera, a także o szczególnych okolicznościach dotyczących tej konfiguracji.

Stos technologii

Backend

• Python 3.6
• Django 1.11
• Django REST Framework 3.9 : serwer jako API, nie renderuje szablonu, nie robi wiele innych rzeczy.
• Django REST Framework JWT 1.11
• Django REST Social Auth <2.1

Frontend

• React : 16.8.3, create-react-appwersja 2.1.5
• Reaguj-google-login : 5.0.2

Przepływ „kodu” (specjalnie dla Google OAuth2)

Podsumowanie: Reaguj -> poproś o „kod” autoryzacji społecznościowej -> zażądaj tokenu jwt, aby uzyskać status „logowania” w odniesieniu do własnego serwera / bazy danych zaplecza.

1. Frontend (React) używa „przycisku logowania Google”, responseType="code"aby uzyskać kod autoryzacyjny. (to nie jest token, nie ma tokena dostępu!)
   • Przycisk logowania do google pochodzi ze react-google-loginwspomnianego powyżej.
   • Kliknięcie tego przycisku spowoduje wyświetlenie wyskakującego okna, w którym użytkownik może wybrać konto. Gdy użytkownik wybierze jeden i okno się zamknie, otrzymasz kod z funkcji wywołania zwrotnego przycisku.
2. Interfejs użytkownika wysyła to do punktu końcowego serwera zaplecza JWT.
   • Żądanie POST, z { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
3. Do mojego serwera Django używam Django REST Framework JWT + Django REST Social Auth. Django otrzymuje kod z interfejsu, zweryfikuj go za pomocą usługi Google (zrobione dla Ciebie). Po zweryfikowaniu wyśle ​​JWT (token) z powrotem do interfejsu. Frontend może teraz zbierać token i przechowywać go gdzieś.
   • Wszystkich REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGINa REST_SOCIAL_OAUTH_REDIRECT_URIw Django settings.pysą niepotrzebne . (Są to stałe używane przez Django REST Social Auth) Krótko mówiąc, nie musisz konfigurować niczego związanego z adresem przekierowującym w Django . Interfejs "redirect_uri": "postmessage"w React wystarczy. Ma to sens, ponieważ praca społecznościowa, którą musisz wykonać po swojej stronie, to wszystkie żądania POST w stylu Ajax w interfejsie, nie przesyłające żadnej formy, więc w rzeczywistości domyślnie nie występuje przekierowanie. Dlatego adres URL przekierowania staje się bezużyteczny, jeśli używasz przepływu kodu + JWT, a ustawienie adresu URL przekierowania po stronie serwera nie działa.
4. Django REST Social Auth obsługuje tworzenie kont. Oznacza to, że sprawdzi adres e-mail / nazwisko konta Google i sprawdzi, czy pasuje do dowolnego konta w bazie danych. Jeśli nie, utworzy je dla Ciebie, używając dokładnego adresu e-mail i imienia. Ale nazwa użytkownika będzie przypominać youremailprefix717e248c5b924d60adres e-mail youremailprefix@example.com. Dodaje losowy ciąg znaków, aby utworzyć unikalną nazwę użytkownika. Jest to zachowanie domyślne, uważam, że można je dostosować i zagłębić się w ich dokumentację.
5. Frontend przechowuje ten token i kiedy musi wykonać CRUD na serwerze backendu, zwłaszcza utworzyć / usunąć / zaktualizować, jeśli podłączysz token do swojego Authorizationnagłówka i wyślesz żądanie do backendu, backend Django rozpozna to jako login, tj. Uwierzytelniony użytkownik. Oczywiście, jeśli twój token straci ważność, musisz go odświeżyć, wysyłając kolejne żądanie.

O mój boże, spędziłem ponad 6 godzin i w końcu udało mi się to dobrze! Wierzę, że to pierwszy raz, kiedy to widziałem postmessage. Każdy, kto pracuje nad Django + DRF + JWT + Social Auth + Reactkombinacją, na pewno się w to wpakuje. Nie mogę uwierzyć, że żaden z wymienionych tam artykułów nie wspomina o tym oprócz odpowiedzi tutaj. Ale naprawdę mam nadzieję, że ten post pozwoli ci zaoszczędzić mnóstwo czasu, jeśli używasz stosu Django + React.

15 lipca 2015 - logowanie, które działało w zeszłym tygodniu z tym skryptem podczas logowania

<script src="https://apis.google.com/js/platform.js" async defer></script>

przestał działać i zaczął powodować błąd 400 z Error: redirect_uri_mismatch

oraz w sekcji SZCZEGÓŁY: redirect_uri=storagerelay://...

rozwiązałem to, zmieniając na:

<script src="https://apis.google.com/js/client:platform.js?onload=startApp"></script>

Lista kontrolna:

• httpczy https?
• &czy &?
• kończący ukośnik ( /) czy otwarty ?
• (CMD/CTRL)+F, wyszukaj dokładne dopasowanie na stronie danych logowania. Jeśli nie znaleziono, wyszukaj brakujący.
• Poczekaj, aż Google go odświeży. Może się zdarzyć co pół godziny, jeśli często się zmieniasz lub może pozostać w basenie. W moim przypadku minęło prawie pół godziny.

W moim przypadku mój typ aplikacji to „Inne”. Więc nie mogę znaleźć Authorized redirect URIsna stronie poświadczeń. Wygląda na to, że pojawia się w polu Typ aplikacji: „Aplikacja internetowa”. Ale możesz kliknąć Download JSONprzycisk, aby uzyskać client_secret.jsonplik.

Otwórz plik json, i można znaleźć parametr takiego: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. Wybieram użycie http: // localhost i działa dla mnie dobrze.

W adresie przekierowania rozróżniana jest wielkość liter.

W moim przypadku dodałem oba: http: // localhost: 5023 / AuthCallback / IndexAsync http: // localhost: 5023 / authcallback / indexasync

Żadne z powyższych rozwiązań nie działało dla mnie. poniżej zrobiłem

zmień autoryzowane adresy URL przekierowania na - https: // localhost: 44377 / signin-google

Mam nadzieję, że to komuś pomoże.

uważaj na dodatkowe /na końcu adresu URL http://localhost:8000różni się odhttp://localhost:8000/

Użytkownicy Railsów (z dokumentów omniauth-google-oauth2 ):

Naprawianie niedopasowania protokołu dla redirect_uri w Railsach

Wystarczy ustawić full_host w OmniAuth na podstawie Rails.env.

# config / initializers / omniauth.rb

OmniAuth.config.full_host = Rails.env.production? ? „ https://domain.com ”: „ http: // localhost: 3000 ”

PAMIĘTAJ: Nie dołączaj końcowego „/”

Jeśli korzystasz z tego samouczka: https://developers.google.com/identity/sign-in/web/server-side-flow , powinieneś użyć „postmessage”.

W GO rozwiązało to problem:

confg = &oauth2.Config{
        RedirectURL:  "postmessage",
        ClientID:   ...,
        ClientSecret: ...,
        Scopes:      ...,
        Endpoint:     google.Endpoint,
}

dla mnie było tak dlatego, że na liście „URI autoryzowanych przekierowań” niepoprawnie wpisałem https://developers.google.com/oauthplayground/zamiast https://developers.google.com/oauthplayground(bez /na końcu).

Pozwólcie, że uzupełnię odpowiedź @ Bazyl: w otrzymanej wiadomości wspomnieli o URI "http://localhost:8080/" (który oczywiście wydaje się wewnętrzną konfiguracją google). Zmieniłem autoryzowany identyfikator URI dla tego "http://localhost:8080/", a wiadomość już się nie pojawiła ... I film został przesłany ... Dokumentacja APIS jest BARDZO kiepska ... Za każdym razem, gdy mam coś do pracy z Google apis, po prostu czuję się „szczęśliwy”, ale brakuje dobrej dokumentacji na ten temat ... :( Tak, działam, ale nie rozumiem jeszcze, dlaczego się nie udało, ani dlaczego zadziałało ... Był tylko JEDEN miejsce, aby potwierdzić identyfikator URI w sieci, a on został skopiowany do client_secrets.json ... Nie dostaję, jeśli istnieje TRZECIE miejsce, w którym należy napisać ten sam URI ... Znajduję nie tylko dokumentację, ale także Projekt GUI Google ”

Każdy, kto próbuje znaleźć miejsce, w którym należy ustawić adresy URL przekierowań w nowej konsoli: Interfejsy API i uwierzytelnianie -> Poświadczenia -> Identyfikatory klientów OAuth 2.0 -> Kliknij link, aby znaleźć wszystkie adresy URL przekierowań

Musiałem utworzyć nowy identyfikator klienta w obszarze Interfejsy API i usługi -> Poświadczenia -> Utwórz poświadczenia -> OAuth -> Inne

Następnie pobrałem plik client_secret.json i korzystałem z niego z moim programem wiersza poleceń, który jest przesyłany na moje konto YouTube. Próbowałem użyć identyfikatora klienta OAuth aplikacji sieci Web, który podawał mi błąd URI przekierowania w przeglądarce.

Spróbuj wykonać następujące kontrole:

1. Identyfikator pakietu w konsoli i aplikacji. Wolę ustawić identyfikator pakietu aplikacji, taki jak ten „org.peredovik. $ {PRODUCT_NAME: rfc1034identifier}”
2. Sprawdź, czy dodałeś typy adresów URL na karcie Informacje, po prostu wpisz swój identyfikator pakietu w polu Identyfikator i Schematy URL, ustaw rolę na Edytor
3. W konsoli na cloud.google.com „Interfejsy API i uwierzytelnianie” -> „Ekran zgody” wypełnij formularz dotyczący Twojej aplikacji. Pole „Nazwa produktu” jest wymagane.

Cieszyć się :)

W moim przypadku musiałem sprawdzić typ identyfikatora klienta dla aplikacji internetowych / zainstalowanych aplikacji.

zainstalowane aplikacje: http: // localhost [przekierowanie URI] W tym przypadku localhost po prostu działa

aplikacje internetowe: Potrzebujesz prawidłowej nazwy domeny [Przekieruj identyfikatory URI:]

Musisz wrócić do konsoli programisty i przejść do interfejsów API i uwierzytelniania> ekranu zgody i wypełnić to. W szczególności nazwa produktu.

Nie zapomnij podać ścieżki po domenie i adresie IP. W moim przypadku zapomniałem:

/ oauth2callback

W konsoli miałem dwa identyfikatory URI żądania : http: // xxxxx / client / api / spreadsheet / authredirect i http: // localhost .

Wypróbowałem wszystkie najlepsze odpowiedzi na to pytanie i potwierdziłem, że żadna z nich nie była moim problemem.

Usunąłem localhost z konsoli, zaktualizowałem mój client_secret.json w moim projekcie i błąd niezgodności zniknął.

Miałem ten sam problem z logowaniem się w Google, miałem zamiar pociągnąć za włosy !!! Poprawnie wpisałem swoje wywołania zwrotne w panelu poświadczeń Google w konsoli programisty Google. Oto moje adresy URL przekierowań:

https://www.example.com/signin-google

https://www.example.com/signin-google/

https://www.example.com/oauth2callback

https://www.example.com/oauth2callback/

wszystko wydaje się w porządku, prawda? ale nadal nie działało, dopóki nie dodałem jeszcze jednego magicznego adresu URL Dodałem adres URL logowania do google (który jest domyślnym wywołaniem zwrotnym Google) bez www i rozwiązany problem.

weź to pod uwagę (w zależności od Twojej domeny), możesz dodać lub nie zarówno adresy URL, jak i bez nich

Mam aplikację frontend i API backend.

Z mojego serwera zaplecza testowałem, naciskając Google API i napotkałem ten błąd. Przez cały czas zastanawiałem się, dlaczego powinienem dawać, redirect_uribo to tylko backend, bo frontend ma sens.

To, co robiłem, to dawanie innego redirect_uri(choć ważnego) od serwera (zakładając, że jest to tylko symbol zastępczy, wystarczy tylko zarejestrować google), ale mój adres frontendowy, który utworzył kod tokena, był inny. Więc kiedy przekazałem ten kod podczas testów po stronie serwera (dla których przekierowanie-uri było inne), miałem do czynienia z tym błędem.

Więc nie rób tego błędu. Upewnij się, że interfejs użytkownika redirect_urijest taki sam jak serwer, ponieważ Google używa go do sprawdzania autentyczności.

Poniżej znajdują się przyczyny błędu: Wystąpił problem z redirect_uri_mismatch:

1. Pole adresu URL przekierowania puste w projekcie Google.
2. Adres przekierowania nie pasuje do Twojej witryny
3. Ważny! Będzie działać tylko z działającą domeną, taką jak example.com, book.com itp. (Nie działa z lokalnym hostem lub adresem URL AWS LB)

Zalecane użycie adresu URL domeny

Sztuczka polega na wprowadzeniu odpowiedniego adresu URL przekierowania w momencie tworzenia identyfikatora. Odkryłem, że aktualizacja adresu URL przekierowania po utworzeniu identyfikatora za pomocą opcji „Edycja” po prostu nie kończy zadania. Dla mnie również zadziałało powielenie całego folderu „dostawcy” i skopiowanie go do tej samej lokalizacji, w której znajduje się plik „oauth” (tylko do momentu pomyślnego wygenerowania tokena, a następnie można usunąć zduplikowany folder „dostawcy”). Jest tak, ponieważ próba wskazania folderu dostawcy za pośrednictwem „../vendor/autoload” nie działała dla mnie.

Tak więc usuń istniejący problematyczny identyfikator OAuth klienta i wypróbuj to podejście, to zadziała.