Praćenje OmniAuth prijave kroz proxy

Korisnik klikne „Prijava“, stigne na stranicu provajdera i vrati se u Rails. Sledeći korak ipak može da propadne jer započinje novu vezu sa Rails servera.

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

Pregledač prati preusmeravanje autorizacije sopstvenom mrežnom konfiguracijom. Rails obavlja razmenu tokena povratnim kanalom koristeći HTTP klijent koji odabere instalirana OmniAuth strategija. Radnik koji radi iza korporativnog proxyja treba tu rutu na svojim zahtevima prema provajderu.

OAuth 1.0 takođe ima serverski korak tokena zahteva pre nego što korisnik odobri pristup. Tok autorizacionog koda OAuth 2.0 ima sopstvenu razmenu tokena nakon povratnog poziva. Tačan redosled zavisi od strategije, ali pregledač i aplikacioni server ostaju različite početne tačke.

Pronađite konfiguraciju klijenta

Pratite strategiju do HTTP klijenta koji šalje njen token i zahteve prema API-ju provajdera. Koristite dokumentovanu opciju proxyja tog klijenta. Neke strategije prosleđuju opcije klijenta OAuth biblioteci; druge konfigurišu HTTP vezu ispod nje. Opcija koju prihvata jedna strategija nije automatski zajednička OmniAuth opcija.

Neka URL-ovi autorizacije, tokena i povratnog poziva provajdera opisuju njegove stvarne usluge. Izlazni proxy je transportno podešavanje za dolazak do provajdera, a ne zamenska adresa povratnog poziva ni polje koje se dodaje parametrima OAuth zahteva.

Kada pratite prijavu, označite poslednji završeni korak. Prikazana stranica prijave provajdera dokazuje da je ruta pregledača radila. Povratni poziv koji Rails primi dokazuje da se pregledač vratio. Sledeći zahtev za token mesto je na kojem treba proveriti proxy vezu, izazov ili odgovor provajdera iz Rails procesa.