Трасування входу 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.