Ответ 1

URI перенаправления (куда возвращается ответ) должен быть зарегистрирован в консоли API, и ошибка указывает на то, что вы этого не сделали или сделали не правильно.

Перейдите в консоль для вашего проекта и посмотрите под API Access. Там вы должны увидеть свой client ID client secret вместе со списком URI перенаправления. Если требуемый URI отсутствует в списке, нажмите "Изменить настройки" и добавьте URI в список.

РЕДАКТИРОВАТЬ: (Из комментария с высокой оценкой ниже) Обратите внимание, что обновление консоли API Google и это изменение может занять некоторое время. Обычно всего несколько минут, но иногда кажется, что это дольше.

Ответ 2

В моем случае это был www и non-www URL. Фактический сайт имел www URL, а Авторизованные URI-адреса перенаправления в Google Developer Console имели non-www URL. Следовательно, было несоответствие в URI перенаправления. Я решил это, обновив Authorized Redirect URIs в Google Developer Console до www URL.

Другим общим несоответствием URI являются:

• Использование http:// в Уполномоченных URI перенаправления и https:// в качестве фактического URL-адреса или наоборот
• Использование конечной косой черты (http://example.com/) в URI с авторизованным перенаправлением и не использовать конечную косую черту (http://example.com) в качестве фактического URL-адреса или наоборот

Ниже приведены пошаговые скриншоты в Google Developer Console, поэтому было бы полезно, если бы пользователям было трудно найти страницу консоли разработчика для обновления URI редиректа.

• Перейдите к https://console.developers.google.com

• Выберите проект

3. Нажмите на значок меню

4. Нажмите API Manager меню

5. Нажмите Credentials меню. И под OAuth 2.0 Client IDs вы найдете свое имя клиента. В моем случае это Web Client 1. Нажмите на него, и появится всплывающее окно, в котором вы сможете редактировать Авторизованный Javascript Origin и Разрешенные URI-адреса перенаправления.

Вот статья Google о создании проекта и идентификатора клиента.

Ответ 3

Если вы используете кнопку Google+ javascript, то вместо фактического URI вы должны использовать postmessage. Мне потребовался почти целый день, чтобы понять это, поскольку Google-документы не ясно излагают это по какой-то причине.

Ответ 4

Для моего веб-приложения я исправил свою ошибку, написав

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

Ответ 5

В любом потоке, в котором вы GoogleAuth.grantOfflineAccess() код авторизации на стороне клиента, например API GoogleAuth.grantOfflineAccess(), и теперь вы хотите передать код на свой сервер, выкупить его, сохранить токены доступа и обновить, затем вы получите использовать postmessage строку postmessage вместо redirect_uri.

Например, на основе фрагмента в документе 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 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"}

Единственная документация Google, в которой даже упоминается postmessage - это старый Google+ документ для входа. Вот скриншот и ссылка на архив, так как G+ закрывается, и эта ссылка, вероятно, исчезнет:

Абсолютно непростительно, что страница документации для автономного доступа не упоминает об этом. #FacePalm

Ответ 6

Обязательно проверьте протокол "http://" или "https://" как протокол проверки google. Лучше добавить оба URL в список.

Ответ 7

Это кажется довольно странным и раздражающим, что нет "одного" решения. для меня http://localhost:8000 не сработало, но http://localhost:8000/ разработано.

Ответ 8

При регистрации своего приложения в https://code.google.com/apis/console и введите идентификатор клиента, вы получите возможность указать один или несколько перенаправлений URIs. Значение параметра redirect_uri в вашем URI авторизации должно точно соответствуют одному из них.

Ответ 9

2015July15 - подпись, которая работала на прошлой неделе с этим script при входе

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

перестает работать и начинает вызывать ошибку 400 с помощью Error: redirect_uri_mismatch

и в разделе DETAILS: redirect_uri=storagerelay://...

я решил это, изменив на:

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

Ответ 10

Контрольный список:

• http или https?
• & или &?
• конечная косая черта (/) или откройте ?
• (CMD/CTRL)+F, найдите точное совпадение на странице учетных данных. Если не найден, затем найдите отсутствующий.
• Подождите, пока Google не обновит его. Может случиться каждые полчаса, если вы часто меняются или могут оставаться в бассейне. Для моего случая было почти полчаса вступить в силу.

Ответ 11

URL-адрес перенаправления чувствителен к регистру.

В моем случае я добавил оба: http://localhost:5023/AuthCallback/IndexAsync http://localhost:5023/AuthCallback/IndexAsync

Ответ 12

Ни один из вышеперечисленных решений не работал у меня. ниже

изменить разрешенные URL-адреса перенаправления на - https://localhost:44377/signin-google

Надеюсь, это поможет кому-то.

Ответ 13

Если вы используете этот учебник: https://developers.google.com/identity/sign-in/web/server-side-flow, тогда вы должны использовать "postmessage".

В GO это исправило проблему:

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

Ответ 14

Этот ответ совпадает с ответом Майка, и ответ Джеффа, оба устанавливает redirect_uri для postmessage на стороне клиента. Я хочу добавить больше о стороне сервера, а также об особых обстоятельствах, применимых к этой конфигурации.

Tech Stack

Backend

• Python 3.6
• Джанго 1.11
• Django REST Framework 3.9: сервер как API, не рендеринг шаблона, не так уж много другого.
• Django REST Framework JWT 1.11
• Django REST Social Auth <2.1

Внешний интерфейс

• Реакция: 16.8.3, версия 2.1.5 create-react-app
• response-google-login: 5.0.2

Поток "Код" (специально для Google OAuth2)

Описание: React → запросить "код" социальной авторизации → запросить токен jwt для получения статуса "логин" с точки зрения вашего собственного внутреннего сервера/базы данных.

1. Frontend (React) использует "кнопку входа Google" с responseType="code" для получения кода авторизации. (это не токен, не токен доступа!)
   • Кнопка входа в react-google-login указана выше как react-google-login.
   • Нажатие на кнопку откроет всплывающее окно для пользователя, чтобы выбрать учетную запись. После того, как пользователь выберет один и окно закроется, вы получите код из функции обратного вызова кнопки.
2. Интерфейс отправляет это на конечную точку JWT внутреннего сервера.
   • POST-запрос с { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
3. Для моего сервера Django я использую Django REST Framework JWT + Django REST Social Auth. Django получает код от внешнего интерфейса, проверьте его с помощью сервиса Google (сделано для вас). После проверки он отправит JWT (токен) обратно во внешний интерфейс. Теперь интерфейс может собрать токен и хранить его где-нибудь.
   • Все REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGIN и REST_SOCIAL_OAUTH_REDIRECT_URI в Django settings.py не нужны. (Это константы, используемые Django REST Social Auth) Короче говоря, вам не нужно ничего настраивать, связанные с перенаправлением URL в Django. "redirect_uri": "postmessage" в интерфейсе React достаточно. Это имеет смысл, поскольку социальная аутентификационная работа, которую вы должны выполнить на своей стороне, - это все POST-запросы в стиле Ajax во внешнем интерфейсе, не отправляющие никаких форм, поэтому фактически перенаправление по умолчанию не происходит. Вот почему URL-адрес перенаправления становится бесполезным, если вы используете поток кода + JWT, а настройка URL-адреса перенаправления на стороне сервера не дает никакого эффекта.
4. Django REST Social Auth управляет созданием аккаунта. Это означает, что он проверит адрес электронной почты/фамилию учетной записи Google и выяснит, соответствует ли она какой-либо учетной записи в базе данных. Если нет, он создаст его для вас, используя точную электронную почту и фамилию. Но имя пользователя будет выглядеть как youremailprefix717e248c5b924d60 если ваш адрес электронной почты - [email protected]. Он добавляет некоторую случайную строку для создания уникального имени пользователя. Это поведение по умолчанию, я считаю, что вы можете настроить его и свободно копаться в их документации.
5. Внешний интерфейс хранит этот токен, и когда он должен выполнить CRUD для внутреннего сервера, особенно создать/удалить/обновить, если вы присоедините токен в заголовке Authorization и отправите запрос к внутреннему интерфейсу, серверная часть Django теперь распознает его как имя входа, т.е. аутентифицированный пользователь. Конечно, если ваш токен истекает, вы должны обновить его, сделав еще один запрос.

О, боже мой, я потратил более 6 часов и наконец понял это правильно! Я полагаю, что это первый раз, когда я увидел это postmessage. Любой, кто работает над комбинацией Django + DRF + JWT + Social Auth + React, обязательно столкнется с этим. Я не могу поверить, что ни одна из статей там не упоминает об этом, кроме ответов здесь. Но я очень надеюсь, что этот пост сэкономит вам массу времени, если вы используете стек Django + React.

Ответ 15

Удаляет пользователей (из omniauth-google-oauth2 docs):

Несоответствие протокола Fixing для redirect_uri в Rails

Просто установите full_host в OmniAuth на основе Rails.env.

# config/initializers/omniauth.rb

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

ПОМНИТЕ: Не включайте конечный "/"

Ответ 16

В моем случае мой учетный тип Тип приложения - "Другое". Поэтому я не могу найти Authorized redirect URIs на странице учетных данных. Кажется, это выглядит в виде приложения: "Веб-приложение". Но вы можете нажать кнопку Download JSON, чтобы получить файл client_secret.json.

Откройте json файл, и вы можете найти такой параметр: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. Я предпочитаю использовать http://localhost, и он отлично подходит для меня.

Ответ 17

остерегайтесь дополнительных / в конце URL-адреса http://localhost:8000 отличается от http://localhost:8000/

Ответ 18

Позвольте мне заполнить @Bazyl ответ: в сообщении, которое я получил, они упомянули URI "http://localhost:8080/" (что, конечно, кажется внутренней конфигурацией Google). Я изменил разрешенный URI для этого, "http://localhost:8080/", и сообщение больше не появилось... И видео загрузилось... Документация APIS ОЧЕНЬ хрома... Каждый раз, когда у меня что-то работает с google apis, я просто чувствую себя "счастливым", но есть недостаток хорошей документации об этом....:( Да, я получил его работу, но я еще не понимаю ни, почему это не удалось, ни почему это сработало... Было только ОДНО место, чтобы подтвердить URI в в Интернете, и он был скопирован в client_secrets.json... Я не понимаю, есть ли ТРЕТЬЕ место, где нужно написать тот же URI... Я нахожу, но не только документацию, но и графический интерфейс Google api вполне хромой...

Ответ 19

Кто-то изо всех сил пытается найти, где задать URL-адреса перенаправления в новой консоли: API и Auth → Учетные данные → Идентификаторы клиента OAuth 2.0 → Нажмите ссылку, чтобы найти все ваши URL-адреса перенаправления

Ответ 20

Мне нужно было создать новый идентификатор клиента в API и службах → Учетные данные → Создать учетные данные → OAuth → Другое

Затем я загрузил и использовал client_secret.json с моей программой командной строки, которая загружается на мою учетную запись youtube. Я пытался использовать идентификатор клиента OAuth для веб-приложений, который давал мне ошибку URI перенаправления в браузере.

Ответ 21

для меня это произошло потому, что в списке "Авторизованные переадресации URI" я неправильно разместил https://developers.google.com/oauthplayground/ вместо https://developers.google.com/oauthplayground (без / в конце),

Ответ 22

Попробуйте выполнить следующие проверки:

• Идентификатор пакета в консоли и в вашем приложении. Я предпочитаю установить Bundle ID приложения как этот "org.peredovik. ${PRODUCT_NAME: rfc1034identifier}"
• Убедитесь, что вы добавили типы URL-адресов на вкладке Info, просто введите свой идентификатор Bundle в идентификаторе и схемах URL-адресов, роль установлена ​​в редакторе
• В консоли на cloud.google.com "APIs and auth" → "Экран согласия" заполните форму о вашем приложении. "Имя продукта" - обязательное поле.

Наслаждайтесь:)

Ответ 23

В моем случае мне пришлось проверять тип идентификатора клиента для веб-приложений/установленных приложений.

установленные приложения: http://localhost [Перенаправление URI] В этом случае localhost просто работает

веб-приложения: вам нужно действительное имя домена [URI перенаправления:]

Ответ 24

Что вам нужно сделать, вернитесь в свою консоль разработчика и перейдите на API и Auth > Consent Screen и заполните это. В частности, название продукта.

Ответ 25

Не забудьте указать путь после домена и ip. В моем случае я забыл:

/oauth2callback

Ответ 26

У меня было два URI запроса в консоли, http://xxxxx/client/api/spreadsheet/authredirect и http://localhost.

Я попробовал все ответы на этот вопрос и подтвердил, что ни одна из них не была моей проблемой.

Я удалил localhost из Консоли, обновил my client_secret.json в своем проекте, и ошибка несоответствия исчезла.

Ответ 27

У меня была такая же проблема с входом google, я собирался вытащить волосы! Я правильно ввел свои обратные вызовы в панели Google Credential на консоли разработчика Google здесь были мои URL-адреса перенаправления:

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

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

https://www.example.com/oauth2callback

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

Кажется, все прекрасно? но он все еще не работал, пока я не добавил еще один магический Url. Я добавил signin-google url (который является обратным вызовом google по умолчанию) без www и проблема решена.

принять во внимание (в зависимости от вашего домена), вам может потребоваться или не нужно добавлять как с URL-адресами, так и без них

Ответ 28

У меня есть приложение frontend и backend api.

На моем серверном сервере я тестировал, нажав google api и столкнулся с этой ошибкой. В течение всего моего времени я задавался вопросом, почему мне нужно дать redirect_uri поскольку это всего лишь бэкэнд, для интерфейса это имеет смысл.

То, что я делал, давало разные redirect_uri (хотя и действительные) с сервера (при условии, что это просто placeholder, его просто нужно зарегистрировать только в google), но мой внешний код, который создал токен-код, был другим. Поэтому, когда я проходил этот код в своем тестировании на стороне сервера (для которого перенаправление-uri было другим), я столкнулся с этой ошибкой.

Так что не делайте этой ошибки. Убедитесь, что интерфейс redirect_uri такой же как ваш сервер, как Google использовать его для проверки подлинности.

Ответ 29

Ниже приводятся причины ошибки: возникает проблема redirect_uri_mismatch:

1. Перенести URL-адрес в проект google.
2. URL-адрес перенаправления не совпадает с вашим сайтом
3. Важный! Он будет работать только с рабочим доменом, например example.com, book.com и т.д. (Не работает с локальным хостом или URL-адресом AWS LB)

Рекомендуется использовать URL-адрес домена

Ответ 30

Хитрость заключается в том, чтобы ввести правильный URL-адрес перенаправления в точке создания идентификатора. Я обнаружил, что обновление URL-адреса перенаправления после того, как идентификатор был создан с помощью "Редактировать", просто не выполняет работу. Для меня также работало дублирование всей папки "vendor" и копирование ее в то же место, где находится файл "oauth" (до тех пор, пока вы успешно не сгенерируете токен, а затем не сможете удалить дубликат папки "vendor"). Это потому, что попытка указать на папку поставщика через "../vendor/autoload" не сработала для меня.

Итак, удалите существующий проблемный идентификатор клиента OAuth и попробуйте этот подход, он будет работать.