На веб-сайті 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

Що означає це повідомлення та як його виправити? Я використовую gem omniauth-google-oauth2 .

URI переспрямування (куди повертається відповідь) повинен бути зареєстрований на консолі API, і помилка вказує на те, що ви цього не зробили чи не зробили це правильно.

Перейдіть до консолі свого проекту та перегляньте розділ API Access. Ви повинні побачити свої client IDта client secretтам, а також список URI-адрес для переадресації. Якщо потрібний URI не вказаний, натисніть редагувати налаштування та додайте URI до списку.

РЕДАКТУВАННЯ: (З коментаря, який високо оцінений нижче) Зауважте, що оновлення консолі api google та зміни, що існують, можуть зайняти деякий час. Як правило, всього кілька хвилин, але іноді це здається довше.

У моєму випадку це був wwwі non-wwwURL. Фактичний сайт мав wwwURL-адресу, а URI- адреси авторизованого перенаправлення в консолі розробника 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. Натисніть на нього, і з’явиться спливаюче вікно, де ви можете редагувати авторизовані джерела JavaScript та авторизовані URI .

Ось стаття Google про створення проекту та ідентифікатора клієнта .

Якщо ви користуєтесь кнопкою javascript Google+ , тоді вам доведеться використовувати 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 + закривається, і це посилання, ймовірно, піде:

Абсолютно непростимо, що сторінка doc для автономного доступу про це не згадує. #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 на стороні клієнта. Я хочу додати більше про сторону сервера, а також особливі обставини, що стосуються цієї конфігурації.

Технологічний стек

Бекенд

• Пітон 3.6
• Джанго 1.11
• Django REST Framework 3.9 : сервер як API, не відображає шаблон, не робить багато іншого.
• Django REST Framework JWT 1.11
• Джанго REST Соціальний аут <2.1

Фронтенд

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

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

Підсумок: React -> запит на соціальний аутентифікатор "код" -> запит jwt токен для отримання статусу "входу" з точки зору вашого власного сервера / бази даних.

1. Frontend (React) використовує "кнопку входу в Google", responseType="code"щоб отримати код авторизації. (це маркер, не маркер доступу!)
   • Кнопка входу в google є react-google-loginзгаданою вище.
   • Натискання на кнопку відкриє спливаюче вікно для вибору користувачем облікового запису. Після того як користувач вибере його і вікно закриється, ви отримаєте код від функції зворотного дзвінка кнопки.
2. Frontend надсилає це на кінцеву точку JWT сервера бекенда.
   • POST-запит, с { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
3. Для свого сервера Django я використовую Django REST Framework JWT + Django REST Social Auth. Джанго отримує код від фронтену, підтверджує його за допомогою сервісу Google (зроблено для вас). Після перевірки він відправить JWT (токен) назад у фронтенд. Тепер Frontend може забирати маркер і зберігати його десь.
   • Усі 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. Frontend зберігає цей маркер і коли йому належить виконати CRUD на сервері бекенда, особливо створити / видалити / оновити, якщо ви додасте маркер у свій Authorizationзаголовок і надішлете запит до бекенда, бекенд Django тепер визнає це як логін, тобто автентифіковано користувач. Звичайно, якщо ваш маркер закінчується, вам доведеться оновити його, подавши ще один запит.

Боже мій, я витратив більше 6 годин і нарешті отримав це право! Я вважаю, що це вперше я бачив цю postmessageріч. Кожен, хто працює над Django + DRF + JWT + Social Auth + Reactкомбінацією, безумовно, вріжеться в це. Я не можу повірити, що жодна стаття там не згадує, крім відповідей тут. Але я дуже сподіваюся, що ця публікація може заощадити багато часу, якщо ви використовуєте стек Django + React.

2015 липня15 - реєстрація, яка працювала минулого тижня з цим сценарієм на вході

<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/

Користувачі рейлів (від документів omniauth-google-oauth2 ):

Виправлення невідповідності протоколу для redirect_uri в Rails

Просто встановіть full_host в OmniAuth на основі Rails.env.

# config / ініціалізатори / 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,
}

для мене це було тому, що в списку "Авторизовані URIs переадресації" я неправильно поставив https://developers.google.com/oauthplayground/замість https://developers.google.com/oauthplayground(без /в кінці).

Дозвольте завершити відповідь @ Bazyl: у повідомленні, яке я отримав, вони згадали URI "http://localhost:8080/" (що, звичайно, здається внутрішньою конфігурацією google). Я змінив авторизований URI для цього "http://localhost:8080/", і повідомлення більше не з’явилося ... І відео було завантажено ... Документація APIS ДУЖЕ кульга ... Щоразу, коли я щось працюю з goisgle apis, я просто відчуваю себе "щасливчиком", але про це бракує гарної документації .... :( Так, я працював, але я ще не розумію ні того, чому він не вдався, ні чому він працював ... Був лише ОДИН місце для підтвердження URI в Інтернеті, і він скопійований у client_secrets.json ... Я не знаю, якщо є ТРЕТИЙ місце, де слід написати той самий URI ... Я знаходжу не тільки документацію, але і GUI-дизайн Google "

Усі люди, які намагаються знайти місце для встановлення URL-адрес переадресації на новій консолі: API та Auth -> Повноважні дані -> Ідентифікатори клієнта OAuth 2.0 -> Клацніть посилання, щоб знайти всі ваші URL-адреси переадресації.

Мені потрібно було створити новий ідентифікатор клієнта в API та службах -> Повноважні дані -> Створити облікові дані -> OAuth -> Інше

Потім я завантажив і використав client_secret.json з моєю програмою командного рядка, яка завантажується в мій обліковий запис YouTube. Я намагався використовувати ідентифікатор клієнта Web App OAuth, який давав мені помилку URI переспрямування в браузері.

Спробуйте зробити ці перевірки:

1. Ідентифікатор групи в консолі та у вашій програмі. Я вважаю за краще встановити ідентифікатор програми Bundle на зразок цього "org.peredovik. $ {PRODUCT_NAME: rfc1034identifier}"
2. Перевірте, чи ви додали типи URL-адрес на вкладці Інформація, просто введіть свій ідентифікатор групи в ідентифікатор і схеми URL-адреси, ролі встановлено в редакторі
3. У консолі на cloud.google.com "API та auth" -> "Екран згоди" заповніть форму про вашу заявку. "Назва продукту" обов'язкове поле.

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

У моєму випадку мені довелося перевірити тип ідентифікатора клієнта для веб-додатків / встановлених програм.

встановлені програми: http: // localhost [Перенаправлення URI] У цьому випадку localhost просто працює

веб-програми: Вам потрібно дійсне ім'я домену [URI, перенаправлення:]

Що вам потрібно зробити, це повернутися до консолі розробника та перейти в API та Auth> Згоден екран та заповнити це. Зокрема, назва продукту.

Не забудьте включити шлях після вашого домену та 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-адресу, я не додав urin signin-google (який є зворотним зворотом google google за замовчуванням) без www та проблеми, яку не вирішено.

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

У мене є додатки для інтерфейсів та бекенд api.

З мого сервера, що пройшов сервер, я тестував, натискаючи goigle api, і зіткнувся з цією помилкою. Протягом усього мого часу мені було цікаво, чому мені потрібно давати, redirect_uriоскільки це просто резерв, для фронтенду це має сенс.

Те, що я робив, давало відмінність redirect_uri(хоча і дійсна) від сервера (припустимо, що це просто заповнювач; він просто повинен бути зареєстрований лише в google), але мій URL-адресу фронтенду, який створив код токена, був іншим. Тому коли я передавав цей код під час тестування на моєму сервері (для якого перенаправлення-урі відрізнявся), я зіткнувся з цією помилкою.

Тому не робіть цієї помилки. Переконайтеся, що ваш інтерфейс redirect_uriтакий, як ваш сервер, як Google використовує його для перевірки справжності.

Нижче наведено причини помилки: виникає проблема redirect_uri_mismatch:

1. Поле для перенаправлення URL-адреси порожнє в проекті Google.
2. URL-адреса переадресації не відповідає вашому сайту
3. Важливо! Він працюватиме лише з робочим доменом, наприклад example.com, book.com тощо (не працює з локальною URL-адресою хоста чи AWS LB)

Рекомендовано використовувати URL-адресу домену

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

Отже, видаліть існуючий проблемний ідентифікатор клієнта OAuth і спробуйте цей підхід, він спрацює.