Ошибка Google OAuth 2 redirect_uri_mismatch при использовании локального переназначения DNS

Question

При локальном тестировании моего приложения ASP.Net я использую инструмент DNS, называемый DNSSpeeder, который принимает процесс DNS для моей машины. Фактически, я могу установить www.mysite.com локально и ввести IP-адрес, например 192.168.178.200, и в моем браузере просто введите www.mysite.com, и он запускается с моего локального веб-сервера IIS. Когда я готов к производству, я просто отключу DNSSpeeder, чтобы DNS DNS использовался для поиска моего сайта.

Проблема, с которой я столкнулся, - это когда я использую Google OAuth для обмена моим кодом на токен. Он возвращается с ошибкой redirect_uri_mismatch. Мне непонятно, что на самом деле происходит на проводе к серверу Google и то, что просматривает URI Google. Переадресация URI соответствует тому, что находится в консоли API, хотя это ничего не говорит о том, что фактически отправлено на сервер Google после того, как он покинул DNSSpeeder. Я попробовал Wireshark, но ничего не показал. Вероятно, зашифрован https. Вместо того, чтобы использовать http://localhost:8080, я пробовал http://localhost:80, а также http://192.168.178.200 для генерации Javascript, но это не помогло.

Возможно ли использовать IP-адрес, отличный от локального, при локальном тестировании, чтобы получить успешный токен?

Answer 1

«Возможно ли использовать IP-адрес, отличный от локального, при локальном тестировании, чтобы получить успешный токен?»

Да, это возможно. Моя настройка заключается в том, что я настроил два URL-адреса переадресации в Cloud Console, (http://www.mydomain.com/redirect и http: // dev .mydomain.com/redirect).

Затем я редактирую/etc/hosts (на linux, Windose эквивалент находится в каталоге system32 \ drivers), чтобы сопоставить dev.mydomain.com с 127.0.0.1.

И все работает отлично. Возможно, вам придется настроить приложение, чтобы URL-адрес перенаправления не был жестко закодирован, но на самом деле он варьируется в зависимости от того, воспринимает ли ваше приложение это в dev или production.

Одна вещь, о которой нужно знать, состоит в том, что конфиденциальный URL-адрес перенаправления должен быть символом для соответствия символа фактическому URL-адресу. Поэтому будьте осторожны, что у вас есть как http, так и https варианты, а также смотрите на трейлинг-косую черту. При необходимости настройте как с завершающей косой чертой, так и без нее.