En el sitio web https://code.google.com/apis/console , registré mi aplicación, configuré el ID de cliente generado y el secreto de cliente en mi aplicación e intenté iniciar sesión con Google. Desafortunadamente, recibí el mensaje de error:
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
¿Qué significa este mensaje y cómo puedo solucionarlo? Yo uso la gema omniauth-google-oauth2 .
authentication
oauth-2.0
google-signin
usuario984621
fuente
fuente
https://accounts.google.com/o/oauth2/auth?client_id={client_id}&response_type=token&redirect_uri={redirect_uri}&scope={scope}
en un navegador, en lugar de ejecutar toda su aplicación para probar.Respuestas:
El URI de redireccionamiento (donde se devuelve la respuesta) debe registrarse en la consola de las API, y el error indica que no lo ha hecho o no lo ha hecho correctamente.
Vaya a la consola para su proyecto y busque en API Access. Debería ver su
client ID
&client secret
allí, junto con una lista de URI de redireccionamiento. Si el URI que desea no aparece en la lista, haga clic en editar configuración y agregue el URI a la lista.EDITAR: (De un comentario altamente calificado a continuación) Tenga en cuenta que actualizar la consola de la API de Google y que el cambio esté presente puede llevar algún tiempo. Generalmente solo unos minutos, pero a veces parece más largo.
fuente
En mi caso fue
www
ynon-www
URL. El sitio real teníawww
URL y los URI de redireccionamiento autorizado en la Consola del desarrollador de Google teníannon-www
URL. Por lo tanto, hubo una falta de coincidencia en el URI de redireccionamiento. Lo resolví actualizandoAuthorized Redirect URIs
en Google Developer Console awww
URL.Otros desajustes comunes de URI son:
http://
en URI de redireccionamiento autorizado yhttps://
como URL real, o viceversahttp://example.com/
) en URI de redireccionamiento autorizado y no utilizar barra diagonal (http://example.com
) como URL real, o viceversaAquí están las capturas de pantalla paso a paso de Google Developer Console para que sea útil para aquellos que tienen dificultades para localizar la página de la consola del desarrollador para actualizar los URI de redireccionamiento.
Aquí hay un artículo de Google sobre la creación de proyectos e ID de clientes .
fuente
Si está utilizando el botón JavaScript de Google+ , debe usarlo en
postmessage
lugar del URI real. Me tomó casi todo el día resolver esto, ya que los documentos de Google no lo indican claramente por alguna razón.fuente
Error: invalid_request
origin parameter is required!
$client->setRedirectUri('postmessage');
lugar de$client->setRedirectUri('http://your.url...');
En cualquier flujo en el que recuperó un código de autorización en el lado del cliente, como la
GoogleAuth.grantOfflineAccess()
API , y ahora desea pasar el código a su servidor, canjearlo y almacenar los tokens de acceso y actualización, debe usar la cadena literalpostmessage
en lugar de redirect_uri.Por ejemplo, basándose en el fragmento en el documento de Ruby :
La única documentación de Google que menciona
postmessage
es este antiguo documento de inicio de sesión de Google+ . Aquí hay una captura de pantalla y un enlace de archivo ya que G + se está cerrando y este enlace probablemente desaparecerá:Es absolutamente imperdonable que la página de documentos para el acceso sin conexión no mencione esto. #FacePalm
fuente
postmessage
, pero quería dar las circunstancias específicas (pgrantOfflineAccess
. ej. ) de cuándo este truco loco indocumentado era necesario para mí. : PI tampoco quería que fuera verdad. :) Me costó horas de dolor de cabeza.Para mi aplicación web, corregí mi error escribiendo
fuente
Asegúrese de verificar el protocolo "http: //" o "https: //" como protocolo de Google Check también. Es mejor agregar ambas URL en la lista.
fuente
Esto parece bastante extraño y molesto porque no hay una solución "única". para mí http: // localhost: 8000 no funcionó pero http: // localhost: 8000 / funcionó.
fuente
redirect_uri
debe a que debe ser un EXACTO EXACTO en la consola de desarrolladores y en su aplicación.Cuando registra su aplicación en https://code.google.com/apis/console y crea una ID de cliente, tiene la oportunidad de especificar uno o más URI de redireccionamiento. El valor del
redirect_uri
parámetro en su URI de autenticación debe coincidir exactamente con uno de ellos.fuente
https://code.google.com/apis/console
ya no es válidaEsta respuesta es la misma que la respuesta de este Mike , y la respuesta de Jeff , ambos conjuntos
redirect_uri
apostmessage
el lado del cliente. Quiero agregar más sobre el lado del servidor, y también las circunstancias especiales que se aplican a esta configuración.Pila de tecnología
Backend
Interfaz
create-react-app
versión 2.1.5El flujo de "Código" (Específicamente para Google OAuth2)
Resumen: Reaccionar -> solicitar "código" de autenticación social -> solicitar token jwt para adquirir el estado de "inicio de sesión" en términos de su propio servidor / base de datos de back-end.
responseType="code"
para obtener un código de autorización. (¡no es token, no token de acceso!)react-google-login
mencionado anteriormente.{ "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI
,REST_SOCIAL_DOMAIN_FROM_ORIGIN
yREST_SOCIAL_OAUTH_REDIRECT_URI
en Django'ssettings.py
son innecesarios . (Son constantes utilizadas por Django REST Social Auth) En resumen, no tiene que configurar nada relacionado con la URL de redireccionamiento en Django . El"redirect_uri": "postmessage"
frontend de In React es suficiente. Esto tiene sentido porque el trabajo de autenticación social que tiene que hacer de su lado es una solicitud POST de estilo Ajax en la interfaz, no envía ningún formulario, por lo que en realidad no se produce una redirección por defecto. Es por eso que la URL de redireccionamiento se vuelve inútil si está utilizando el código + flujo JWT, y la configuración de la URL de redireccionamiento del lado del servidor no está teniendo ningún efecto.youremailprefix717e248c5b924d60
si su correo electrónico es[email protected]
. Agrega una cadena aleatoria para hacer un nombre de usuario único. Este es el comportamiento predeterminado, creo que puede personalizarlo y no dude en profundizar en su documentación.Authorization
encabezado y envía la solicitud al backend, el backend de Django ahora lo reconocerá como un inicio de sesión, es decir, autenticado usuario. Por supuesto, si su token caduca, debe actualizarlo haciendo otra solicitud.¡Oh Dios mío, he pasado más de 6 horas y finalmente lo hice bien! Creo que es la primera vez que veo esto
postmessage
. Cualquiera que trabaje en unaDjango + DRF + JWT + Social Auth + React
combinación definitivamente chocará con esto. No puedo creer que nada del artículo mencione esto, excepto las respuestas aquí. Pero realmente espero que esta publicación pueda ahorrarle mucho tiempo si está usando la pila Django + React.fuente
201515 de julio: el inicio de sesión que funcionaba la semana pasada con este script al iniciar sesión
dejó de funcionar y comenzó a causar el error 400 con
Error: redirect_uri_mismatch
y en la sección DETALLES:
redirect_uri=storagerelay://...
Lo resolví cambiando a:
fuente
Lista de Verificación:
http
ohttps
?&
o&
?/
) o abierta?
(CMD/CTRL)+F
, busque la coincidencia exacta en la página de credenciales. Si no se encuentra, busque el que falta.fuente
En mi caso, mi tipo de solicitud de credencial es "Otro". Entonces no puedo encontrar
Authorized redirect URIs
en la página de credenciales. Parece que aparece en Tipo de aplicación: "Aplicación web". Pero puede hacer clic en elDownload JSON
botón para obtener elclient_secret.json
archivo.Abra el archivo JSON, y se puede encontrar el parámetro de la siguiente manera:
"redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]
. Elijo usar http: // localhost y funciona bien para mí.fuente
La URL de redireccionamiento distingue entre mayúsculas y minúsculas.
En mi caso, agregué ambos: http: // localhost: 5023 / AuthCallback / IndexAsync http: // localhost: 5023 / authcallback / indexasync
fuente
Ninguna de las soluciones anteriores funcionó para mí. abajo hizo
cambie las URL de redireccionamiento autorizadas a - https: // localhost: 44377 / signin-google
Espero que esto ayude a alguien.
fuente
cuidado con el extra
/
al final de la urlhttp://localhost:8000
es diferente dehttp://localhost:8000/
fuente
Usuarios de Rails (de los documentos omniauth-google-oauth2 ):
RECUERDE: No incluya el "/" final
fuente
Si usa este tutorial: https://developers.google.com/identity/sign-in/web/server-side-flow, entonces debe usar "postmessage".
En GO, esto solucionó el problema:
fuente
para mí fue porque en la lista 'URI de redireccionamiento autorizado' he colocado incorrectamente en
https://developers.google.com/oauthplayground/
lugar dehttps://developers.google.com/oauthplayground
(sin/
al final).fuente
Permítanme completar la respuesta de @ Bazyl: en el mensaje que recibí, mencionaron el URI
"http://localhost:8080/"
(que, por supuesto, parece una configuración interna de Google). Cambié el URI autorizado para ese"http://localhost:8080/"
, y el mensaje ya no apareció ... Y el video se subió ... La documentación de APIS es MUY lamentable ... Cada vez que tengo algo trabajando con google apis, simplemente me siento "afortunado", pero falta una buena documentación al respecto ... :( Sí, lo hice funcionar, pero aún no entiendo por qué falló ni por qué funcionó ... Solo había UNO lugar para confirmar el URI en la web, y se copió en client_secrets.json ... No entiendo si hay un TERCER lugar donde se debe escribir el mismo URI ... No encuentro solo la documentación sino también el Diseño GUI de Google 'fuente
Cualquiera que tenga dificultades para encontrar dónde configurar las URL de redireccionamiento en la nueva consola: API y autenticación -> Credenciales -> ID de cliente OAuth 2.0 -> Haga clic en el enlace para encontrar todas sus URL de redireccionamiento
fuente
Necesitaba crear una nueva ID de cliente en API y servicios -> Credenciales -> Crear credenciales -> OAuth -> Otro
Luego descargué y utilicé client_secret.json con mi programa de línea de comandos que se está cargando en mi cuenta de YouTube. Estaba tratando de usar un ID de cliente OAuth de aplicación web que me estaba dando el error de redireccionamiento URI en el navegador.
fuente
Intenta hacer estos controles:
Disfruta :)
fuente
En mi caso, tuve que verificar el tipo de ID de cliente para aplicaciones web / aplicaciones instaladas.
aplicaciones instaladas: http: // localhost [Redirigir URI] En este caso, localhost simplemente funciona
aplicaciones web: necesita un nombre de dominio válido [URI de redireccionamiento:]
fuente
Lo que debe hacer es volver a su Consola de desarrollador e ir a APIs y autenticación> Pantalla de consentimiento y completarlo. Específicamente, el nombre del producto.
fuente
No olvide incluir la ruta después de su dominio e ip. En mi caso, olvidé:
/ oauth2callback
fuente
Tenía dos URI de solicitud en la consola, http: // xxxxx / client / api / spreadsheet / authredirect y http: // localhost .
Intenté todas las respuestas principales a esta pregunta y confirmó que ninguna de ellas era mi problema.
Eliminé localhost de la consola, actualicé mi client_secret.json en mi proyecto y desapareció el error de falta de coincidencia.
fuente
Tuve el mismo problema con el inicio de sesión de Google, estaba a punto de arrancarme el pelo. Ingresé correctamente mis devoluciones de llamada en el panel de credenciales de Google en la consola de desarrolladores de Google, aquí estaban mis URL de redireccionamiento:
https://www.example.com/signin-google
https://www.example.com/signin-google/
https://www.example.com/oauth2callback
https://www.example.com/oauth2callback/
todo parece estar bien, ¿verdad? pero aún no funcionaba hasta que he añadido una más mágica Url añadí signin-google url (que es por defecto Google devolución de llamada) y sin www y problema resuelto.
téngalo en cuenta (dependiendo de su dominio) puede que necesite o no agregar ambos con y sin www urls
fuente
Tengo una aplicación frontend y una API de backend.
Desde mi servidor de back-end estaba probando presionando la API de Google y enfrentaba este error. Durante todo mi tiempo me preguntaba por qué debería tener que dar,
redirect_uri
ya que esto es solo el back-end, ya que la interfaz tiene sentido.Lo que estaba haciendo era dar un
redirect_uri
servidor diferente (aunque válido) (suponiendo que esto sea solo un marcador de posición, solo tiene que estar registrado en Google), pero mi URL de la interfaz que creó el código de token fue diferente. Entonces, cuando pasaba este código en las pruebas del lado del servidor (para las cuales redirect-uri era diferente), me enfrentaba a este error.Así que no cometas este error. Asegúrese de que su interfaz
redirect_uri
sea la misma que la de su servidor, ya que Google la usa para validar la autenticidad.fuente
A continuación se detallan los motivos del error: se produce el problema de redirect_uri_mismatch:
Recomendado para usar la URL del dominio
fuente
El truco consiste en ingresar la URL de redireccionamiento correcta al momento de crear la ID. Descubrí que actualizar la URL de redireccionamiento una vez que se ha creado la ID a través de una 'Edición' simplemente no hace el trabajo. Lo que también funcionó para mí es duplicar toda la carpeta 'proveedor' y copiarla en la misma ubicación donde está el archivo 'oauth' (solo hasta que genere con éxito el token y luego pueda eliminar la carpeta duplicada 'proveedor'). Esto se debe a que intentar señalar la carpeta del proveedor a través de '../vendor/autoload' no funcionó para mí.
Por lo tanto, elimine su problemática ID de cliente OAuth existente y pruebe este enfoque, funcionará.
fuente