Google OAuth 2-autorisatie – Fout: redirect_uri_mismatch

Op de website https://code.google.com/apis/consoleheb ik mijn applicatie geregistreerd, stel up gegenereerde Client ID:en Client Secretvoor mijn app en probeerde in te loggen met Google.
Helaas kreeg ik de foutmelding:

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

Wat betekent dit bericht en hoe kan ik het oplossen?
Ik gebruik de edelsteen omniauth-google-oauth2.


Antwoord 1, autoriteit 100%

De omleidings-URI (waar het antwoord naar wordt teruggestuurd) moet worden geregistreerd in de API’s-console en de fout geeft aan dat u dat niet of niet correct hebt gedaan.

Ga naar de console voor uw project en kijk onder API-toegang. U zou uw client ID& client secretdaar, samen met een lijst met omleidings-URI’s. Als de gewenste URI niet in de lijst staat, klikt u op Instellingen bewerken en voegt u de URI toe aan de lijst.

BEWERKEN: (Uit een zeer gewaardeerde opmerking hieronder) Houd er rekening mee dat het bijwerken van de Google API-console en de aanwezige wijziging enige tijd kan duren. Meestal maar een paar minuten, maar soms lijkt het langer.


Antwoord 2, autoriteit 30%

In mijn geval was het wwwen non-wwwURL. De werkelijke site had een www-URL en de Geautoriseerde omleidings-URI’sin de Google Developer Console hadden een non-www-URL. Daarom was er een mismatch in de omleidings-URI. Ik heb het opgelost door Authorized Redirect URIsin de Google Developer Console bij te werken naar wwwURL.

Andere veelvoorkomende URI-mismatches zijn:

  • http://gebruiken in geautoriseerde omleidings-URI’s en https://als daadwerkelijke URL, of omgekeerd
  • Gebruik een slash (http://example.com/) in geautoriseerde omleidings-URI’s en geen slash (http://example.com) als daadwerkelijke URL, of omgekeerd

Hier zijn de stapsgewijze screenshots van de Google Developer Console, zodat het handig zou zijn voor degenen die het moeilijk hebben om de pagina van de ontwikkelaarsconsole te vinden om omleidings-URI’s bij te werken.

  1. Ga naar https://console.developers.google.com

  2. Selecteer uw project

Selecteer uw project

  1. Klik op het menupictogram

Klik op het menupictogram

  1. Klik op het menu API Manager

Selecteer API Manager-menu

  1. Klik op het menu Credentials. En onder OAuth 2.0 Client IDsvindt u uw klantnaam. In mijn geval is dat Web Client 1. Klik erop en er verschijnt een pop-up waarin u Geautoriseerde Javascript Originen Geautoriseerde omleidings-URI’skunt bewerken.

Selecteer het inloggegevensmenu

Opmerking: De geautoriseerde URI bevat standaard alle localhost-links en elke live-versie moet het volledige pad bevatten, niet alleen het domein, b.v. https://example.com/path/to/oauth/url

Hier is een Google-artikel over het maken van een project- en klant-ID.


Antwoord 3, autoriteit 24%

Als u de Google+ javascript-knopgebruikt, moet u postmessagegebruiken in plaats van de daadwerkelijke URI. Het kostte me bijna de hele dag om dit uit te zoeken, aangezien de documenten van Google dit om de een of andere reden niet duidelijk vermelden.


Antwoord 4, autoriteit 17%

In elke stroom waarbij u een autorisatiecodeaan de clientzijde heeft opgehaald, zoals de GoogleAuth.grantOfflineAccess()API, en nu wilt u de code doorgeven aan uw server, deze inwisselen, en de toegangs- en vernieuwingstokens opslaat, dan moet je de letterlijke tekenreeks postmessagegebruiken in plaats van de redirect_uri.

Bijvoorbeeld voortbouwen op het fragment in het Ruby-document:

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"}

De enige Google-documentatie die zelfs maar melding maakt van postmessageis deze oude Google+ aanmeldingsdocument. Hier is een screenshot en archieflinkaangezien G+ wordt gesloten en deze link waarschijnlijk zal verdwijnen:

Oude Google+ API DOC

Het is absoluut onvergeeflijk dat de documentpagina voor offline toegangvermeldt dit niet. #FacePalm


Antwoord 5, autoriteit 11%

Voor mijn webapplicatie heb ik mijn fout gecorrigeerd door te schrijven

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

Antwoord 6, autoriteit 8%

Controleer het protocol “http://” of “https://”, aangezien Google het protocol ook controleert.
Het is beter om beide URL’s aan de lijst toe te voegen.


Antwoord 7, autoriteit 2%

Dit lijkt nogal vreemd en vervelend dat er geen “één” oplossing is.
voor mij werkte http://localhost:8000niet, maar http://localhost:8000/uitgewerkt.


Antwoord 8, autoriteit 2%

Checklist:

  • httpof https?
  • &of &amp;?
  • slash(/) of open ?
  • (CMD/CTRL)+F, zoek naar de exacte overeenkomst op de inlogpagina. Indien
    niet gevonden zoek dan naar de ontbrekende.
  • Wacht tot Google het ververst. Kan gebeuren in elk half uur als je
    vaak veranderen of het kan in het zwembad blijven. In mijn geval duurde het bijna een half uur voordat het effect had.

Antwoord 9

Wanneer u uw app registreert op https://code.google.com/apis/consoleen
maak een klant-ID, je krijgt de kans om een of meer omleidingen op te geven
URI’s. De waarde van de parameter redirect_uriop uw auth-URI moet
overeenkomen met een van hen precies.


Antwoord 10

2015Juli15 – de aanmelding die vorige week werkte met dit script bij aanmelding

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

werkte niet meer en begon Error 400 te veroorzaken met Error: redirect_uri_mismatch

en in het gedeelte DETAILS: redirect_uri=storagerelay://...

ik heb het opgelost door te veranderen in:

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

Antwoord 11

In mijn geval is mijn aanmeldingstype ‘Overige’. Dus ik kan Authorized redirect URIsniet vinden op de pagina met inloggegevens. Het lijkt te verschijnen in Toepassingstype:”Webtoepassing”. Maar u kunt op de knop Download JSONklikken om het bestand client_secret.jsonop te halen.
voer hier de afbeeldingsbeschrijving in

Open het json-bestand en je kunt de parameter als volgt vinden: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. Ik kies ervoor om http://localhostte gebruiken en het werkt prima voor mij.


Antwoord 12

Als je deze tutorial gebruikt: https://developers. google.com/identity/sign-in/web/server-side-flowdan moet je “postmessage” gebruiken.

In GO loste dit het probleem op:

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

Antwoord 13

pas op voor de extra /aan het einde van de url
http://localhost:8000is anders dan http://localhost:8000/


Antwoord 14

De omleidings-URL is hoofdlettergevoelig.

In mijn geval heb ik beide toegevoegd:
http://localhost:5023/AuthCallback/IndexAsync
http://localhost:5023/authcallback/indexasync


Antwoord 15

Rails-gebruikers (uit de omniauth-google-oauth2documenten):

Protocol-mismatch voor redirect_uri in Rails oplossen

Stel gewoon de full_host in OmniAuth in op basis van Rails.env.

# config/initializers/omniauth.rb

OmniAuth.config.full_host = Rails.env.productie? ? ‘https://domain.com‘ : ‘http://localhost:3000

ONTHOUD: voeg geen “/” achteraan toe


Antwoord 16

Geen van de bovenstaande oplossingen werkte voor mij. hieronder deed

gemachtigde omleidings-URL’s wijzigen in – https://localhost:44377/signin-google

Ik hoop dat dit iemand helpt.


Antwoord 17

voor mij was het omdat ik in de lijst ‘Geautoriseerde omleidings-URI’s’ ten onrechte https://developers.google.com/oauthplayground/heb geplaatst in plaats van https://developers.google.com/oauthplayground(zonder /aan het einde).


Antwoord 18

Zorg er wel voor dat u een URL invoert en niet alleen een domein.
Dus in plaats van:
domein.com
het zou moeten zijn
domain.com/somePathWhereYouHadleYourRedirect


Antwoord 19

Iedereen die moeite heeft om te vinden waar omleidings-URL’s moeten worden ingesteld in de nieuwe console: API’s & Auth -> Inloggegevens -> OAuth 2.0-client-ID’s -> Klik op de link om al uw omleidings-URL’s te vinden


Antwoord 20

Mijn probleem was dat ik http://localhost:3000/ in de adresbalk had en http:// had 127.0.0.1:3000/in console.developers.google.com

voer hier de afbeeldingsbeschrijving in

voer hier de afbeeldingsbeschrijving in


Antwoord 21

Laat me het antwoord van @Bazyl aanvullen: in het bericht dat ik ontving, noemden ze de URI
"http://localhost:8080/"
(wat natuurlijk een interne Google-configuratie lijkt). Ik heb de geautoriseerde URI voor die gewijzigd,
"http://localhost:8080/", en het bericht verscheen niet meer… En de video werd geüpload… De APIS-documentatie is ZEER zwak… Elke keer als ik iets dat werkt met google apis, ik voel me gewoon “gelukkig”, maar er is een gebrek aan goede documentatie erover …. 🙁 Ja, ik heb het werkend, maar ik begrijp nog niet waarom het mislukte, noch waarom het werkte… Er was maar ÉÉN plaats om de URI op het web te bevestigen, en het werd gekopieerd in de client_secrets.json… Ik snap niet of er een DERDE plaats is waar men dezelfde URI zou moeten schrijven… Ik vind niet alleen de documentatie maar ook het GUI-ontwerp van Google’s api nogal zwak…


Antwoord 22

Ik moest een nieuwe klant-ID maken onder API’s & Diensten -> Inloggegevens -> Inloggegevens maken -> OAuth -> Anders

Vervolgens heb ik client_secret.json gedownload en gebruikt met mijn opdrachtregelprogramma dat wordt geüpload naar mijn YouTube-account. Ik probeerde een Web App OAuth-client-ID te gebruiken die me de omleidings-URI-fout in de browser gaf.


Antwoord 23

Ik heb een frontend app en backend api.

Vanaf mijn backend-server was ik aan het testen door google api te gebruiken en kreeg deze fout te maken. Gedurende mijn hele tijd vroeg ik me af waarom ik redirect_urizou moeten geven, aangezien dit slechts de backend is, voor frontend is het logisch.

Wat ik aan het doen was, was verschillende redirect_uri(hoewel geldig) van de server geven (ervan uitgaande dat dit slechts een tijdelijke aanduiding is, hoeft het alleen maar te worden geregistreerd bij Google), maar mijn frontend-URL die tokencode heeft gemaakt, was verschillend. Dus toen ik deze code doorgaf in mijn server-side-test (waarvoor redirect-uri anders was), kreeg ik te maken met deze fout.

Dus maak deze fout niet. Zorg ervoor dat uw frontend redirect_urihetzelfde is als die van uw server, aangezien Google deze gebruikt om de authenticiteit te valideren.


Antwoord 24

De belangrijkste reden voor dit probleem komt alleen van Chrome en Chrome-handvatten WWW en niet www anders, afhankelijk van hoe u uw URL in de browsers hebt ingevoerd en het zoekt vanuit Google en toont direct de resultaten, dus de verzonden omleidings-URL is anders in een ander geval

voer hier de afbeeldingsbeschrijving in

Voeg alle mogelijke combinaties toe die u kunt vinden, de exacte url die door fiddler is verzonden, de 400-foutpop-up geeft u niet de exacte http- en www-informatie


Antwoord 25

Mijn twee cent:
Als u de bibliotheek Google_Clientgebruikt, vergeet dan niet om het JSON-bestand op uw server bij te werken na het bijwerken van de omleidings-URI’s.


Antwoord 26

Probeer deze controles uit te voeren:

  1. Bundel-ID in console en in uw applicatie. Ik geef de voorkeur aan een set Bundel-ID van de applicatie zoals deze “org.peredovik.${PRODUCT_NAME:rfc1034identifier}”
  2. Controleer of je URL-typen hebt toegevoegd op het tabblad Info typ je bundel-ID in Identifier en URL-schema’s, rol ingesteld op Editor
  3. In console op cloud.google.com “API’s & auth” -> Vul het formulier “Toestemmingsscherm” in over uw aanvraag. “Productnaam” is een verplicht veld.

Veel plezier 🙂


Antwoord 27

In mijn geval moest ik het type Client ID controleren voor webapplicaties/geïnstalleerde applicaties.

geïnstalleerde applicaties: http://localhost[Redirect URI’s]
In dit geval werkt localhost gewoon

webapplicaties: u heeft een geldige domeinnaam nodig [Redirect URI’s:]


Antwoord 28

Wat u moet doen, is teruggaan naar uw ontwikkelaarsconsole en naar API’s & Auth > Toestemmingsscherm en vul dat in. Met name de productnaam.


Antwoord 29

Ik had twee verzoek-URI’s in de console, http://xxxxx/client/api/spreadsheet/ authredirecten http://localhost.

Ik heb alle beste antwoorden op deze vraag geprobeerd en heb bevestigd dat geen van deze mijn probleem was.

Ik heb localhost uit de console verwijderd, mijn client_secret.json in mijn project bijgewerkt en de mismatch-fout is verdwenen.

Other episodes