Трассировка входа OmniAuth через прокси

Пользователь нажимает «Войти», попадает на страницу провайдера и возвращается в Rails. Следующий шаг всё равно может завершиться ошибкой, потому что он открывает новое соединение с сервера Rails.

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

Браузер выполняет перенаправление авторизации со своей собственной сетевой конфигурацией. Rails выполняет обмен токеном по обратному каналу через HTTP-клиент, выбранный установленной стратегией OmniAuth. Рабочему процессу за корпоративным прокси нужен этот маршрут в запросах к провайдеру.

В OAuth 1.0 также есть серверный шаг получения токена запроса до того, как пользователь разрешит доступ. В потоке кода авторизации OAuth 2.0 есть собственный обмен токеном после обратного вызова. Точная последовательность зависит от стратегии, но браузер и сервер приложения остаются разными отправными точками.

Найдите конфигурацию клиента

Пройдите по стратегии до HTTP-клиента, который отправляет её токен и запросы к API провайдера. Используйте документированную опцию прокси этого клиента. Некоторые стратегии передают параметры клиента в библиотеку OAuth; другие настраивают HTTP-соединение под ней. Опция, которую принимает одна стратегия, не становится автоматически общей опцией OmniAuth.

Пусть URL-адреса авторизации, токена и обратного вызова провайдера описывают его реальные сервисы. Исходящий прокси — это транспортная настройка для доступа к провайдеру, а не замена адреса обратного вызова и не поле, которое добавляют в параметры запроса OAuth.

При трассировке входа отмечайте последний завершённый шаг. Показанная страница входа провайдера доказывает, что маршрут браузера сработал. Полученный Rails обратный вызов доказывает, что браузер вернулся. Следующий запрос токена — это место, где нужно проверять прокси-соединение, запрос проверки или ответ провайдера со стороны процесса Rails.