Śledzenie logowania OmniAuth przez serwer proxy

Użytkownik klika „Zaloguj się”, trafia na stronę dostawcy i wraca do Rails. Następny krok nadal może się nie udać, ponieważ otwiera nowe połączenie z serwera Rails.

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

Przeglądarka realizuje przekierowanie autoryzacyjne zgodnie z własną konfiguracją sieci. Rails wykonuje wymianę tokenu kanałem zwrotnym za pomocą klienta HTTP wybranego przez zainstalowaną strategię OmniAuth. Proces działający za firmowym proxy potrzebuje tej trasy w żądaniach do dostawcy.

OAuth 1.0 również ma po stronie serwera krok tokenu żądania, zanim użytkownik autoryzuje dostęp. Przepływ kodu autoryzacji OAuth 2.0 ma własną wymianę tokenu po wywołaniu zwrotnym. Dokładna kolejność zależy od strategii, ale przeglądarka i serwer aplikacji pozostają odrębnymi punktami wyjścia.

Znajdź konfigurację klienta

Prześledź strategię aż do klienta HTTP, który wysyła jej token i żądania do API dostawcy. Użyj udokumentowanej opcji proxy tego klienta. Niektóre strategie przekazują opcje klienta do biblioteki OAuth, inne konfigurują połączenie HTTP pod nią. Opcja akceptowana przez jedną strategię nie jest automatycznie wspólną opcją OmniAuth.

Pozwól, aby adresy autoryzacji, tokenu i wywołania zwrotnego dostawcy opisywały jego rzeczywiste usługi. Wychodzące proxy to ustawienie transportu do dotarcia do dostawcy, a nie zastępczy adres wywołania zwrotnego ani pole dodawane do parametrów żądania OAuth.

Śledząc logowanie, oznacz ostatni ukończony krok. Wyświetlona strona logowania dostawcy dowodzi, że trasa przeglądarki zadziałała. Wywołanie zwrotne odebrane przez Rails dowodzi, że przeglądarka wróciła. Kolejne żądanie tokenu to miejsce, w którym należy sprawdzić połączenie proxy, wyzwanie lub odpowiedź dostawcy z procesu Rails.