На веб-сайте https://code.google.com/apis/console я зарегистрировал свое приложение, настроил сгенерированный идентификатор клиента: и Client Secret для своего приложения и попытался войти в систему с помощью Google. К сожалению, я получил сообщение об ошибке:

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

Что означает это сообщение, и как я могу это исправить? Я использую драгоценный камень omniauth-google-oauth2 .

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

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

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

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

Другие распространенные несоответствия URI:

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

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

1. Перейдите на страницу https://console.developers.google.com.

2. Выберите свой проект

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

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

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

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

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

В любом потоке, в котором вы получили код авторизации на стороне клиента, например, GoogleAuth.grantOfflineAccess()API , и теперь вы хотите передать код на сервер, выкупить его, сохранить токены доступа и обновить, тогда вам придется использовать буквенную строку 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'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"}

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

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

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

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

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

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

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

Этот ответ так же , как ответить на этот вопрос Майка , и ответ Джеффа , оба набора 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, create-react-appверсия 2.1.5
• response-google-login : 5.0.2

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

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

1. Frontend (React) использует «кнопку входа Google», responseType="code"чтобы получить код авторизации. (это не токен, не токен доступа!)
   • Кнопка входа в Google из 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в Джанго, settings.pyне нужны . (Это константы, используемые Django REST Social Auth) Короче говоря, вам не нужно ничего настраивать, связанные с перенаправлением URL в Django . "redirect_uri": "postmessage"В React внешнего интерфейса достаточно. Это имеет смысл, потому что социальная работа по аутентификации, которую вы должны выполнить на своей стороне, - это все POST-запросы в стиле Ajax во внешнем интерфейсе, без отправки какой-либо формы, поэтому по умолчанию перенаправление не происходит. Вот почему URL-адрес перенаправления становится бесполезным, если вы используете поток кода + JWT, а настройка URL-адреса перенаправления на стороне сервера не дает никакого эффекта.
4. Django REST Social Auth управляет созданием аккаунта. Это означает, что он проверит адрес электронной почты / фамилию учетной записи Google и выяснит, соответствует ли она какой-либо учетной записи в базе данных. Если нет, он создаст его для вас, используя точную электронную почту и фамилию. Но имя пользователя будет примерно таким, как youremailprefix717e248c5b924d60если бы ваш адрес электронной почты был youremailprefix@example.com. Он добавляет некоторую случайную строку для создания уникального имени пользователя. Это поведение по умолчанию, я считаю, что вы можете настроить его и свободно копаться в их документации.
5. Внешний интерфейс хранит этот токен, и когда он должен выполнить CRUD для внутреннего сервера, особенно создать / удалить / обновить, если вы прикрепите токен в свой Authorizationзаголовок и отправите запрос к внутреннему интерфейсу, серверный интерфейс Django теперь распознает его как имя входа, то есть аутентифицированное пользователь. Конечно, если ваш токен истекает, вы должны обновить его, сделав еще один запрос.

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

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

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

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

и в разделе ДЕТАЛИ: redirect_uri=storagerelay://...

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

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

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

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

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

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

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

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

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

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

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

Остерегайтесь лишнего /в конце URL http://localhost:8000отличается отhttp://localhost:8000/

Пользователи Rails (из документации omniauth-google-oauth2 ):

Исправление несоответствия протокола для 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 '

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

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

В GO это решило проблему:

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

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

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

Любой, кто пытается найти, где установить URL-адреса перенаправления в новой консоли: APIs & Auth -> Credentials -> идентификаторы клиента OAuth 2.0 -> Нажмите на ссылку, чтобы найти все ваши URL-адреса перенаправления

Мне нужно было создать новый идентификатор клиента в разделе «APIs & Services» -> «Учетные данные» -> «Создать учетные данные» -> OAuth -> «Другие».

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

Попробуйте сделать эти проверки:

1. Идентификатор пакета в консоли и в вашем приложении. Я предпочитаю устанавливать Bundle ID приложения, например, «org.peredovik. $ {PRODUCT_NAME: rfc1034identifier}»
2. Проверьте, добавили ли вы типы URL-адресов на вкладке «Информация», просто введите свой идентификатор пакета в «Идентификатор» и «Схемы URL-адресов», для роли установите значение «Редактор».
3. В консоли на cloud.google.com "APIs & auth" -> "Экран согласия" заполните форму о вашем приложении. Поле «Название продукта» обязательно для заполнения.

Наслаждаться :)

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

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

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

Что вам нужно сделать, это вернуться в консоль разработчика и перейти к API-интерфейсам и авторизации> Экран согласия и заполнить его. В частности, название продукта.

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

/ oauth2callback

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

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

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

У меня была та же проблема с входом в Google, я собирался вырвать мои волосы !!! Я правильно ввел свои обратные вызовы на панели учетных данных Google на консоли разработчика 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-адресами, так и без них.

У меня есть приложение внешнего интерфейса и интерфейс API.

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

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

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

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

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

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

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

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