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 secret
daar, 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 www
en non-www
URL. 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 URIs
in de Google Developer Console bij te werken naar www
URL.
Andere veelvoorkomende URI-mismatches zijn:
http://
gebruiken in geautoriseerde omleidings-URI’s enhttps://
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.
Selecteer uw project
- Klik op het menupictogram
- Klik op het menu
API Manager
- Klik op het menu
Credentials
. En onderOAuth 2.0 Client IDs
vindt u uw klantnaam. In mijn geval is datWeb Client 1
. Klik erop en er verschijnt een pop-up waarin u Geautoriseerde Javascript Originen Geautoriseerde omleidings-URI’skunt bewerken.
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 postmessage
gebruiken 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 postmessage
gebruiken 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 postmessage
is deze oude Google+ aanmeldingsdocument. Hier is een screenshot en archieflinkaangezien G+ wordt gesloten en deze link waarschijnlijk zal verdwijnen:
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:
http
ofhttps
?&
of&
?- 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_uri
op 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 URIs
niet vinden op de pagina met inloggegevens. Het lijkt te verschijnen in Toepassingstype:”Webtoepassing”. Maar u kunt op de knop Download JSON
klikken om het bestand client_secret.json
op te halen.
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:8000
is 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
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_uri
zou 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_uri
hetzelfde 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
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:
- 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}”
- 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
- 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.