Uporabnik klikne »Prijava«, doseže stran ponudnika in se vrne v Rails. Naslednji korak lahko še vedno ne uspe, ker odpre novo povezavo s strežnika Rails.

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

Brskalnik izvede preusmeritev za avtorizacijo z lastno omrežno konfiguracijo. Rails izmenjavo žetona opravi po povratnem kanalu s klientom HTTP, ki ga izbere nameščena strategija OmniAuth. Delovni proces za poslovnim posredniškim strežnikom potrebuje to pot pri zahtevah do ponudnika.

Tudi OAuth 1.0 ima na strežniku korak z žetonom zahteve, preden uporabnik odobri dostop. Tok avtorizacijske kode OAuth 2.0 ima po povratnem klicu svojo izmenjavo žetona. Natančno zaporedje je odvisno od strategije, vendar brskalnik in aplikacijski strežnik ostaneta različni izhodišči.

Poiščite konfiguracijo odjemalca

Sledite strategiji do klienta HTTP, ki pošilja njen žeton in zahteve do API-ja ponudnika. Uporabite dokumentirano možnost posredniškega strežnika tega odjemalca. Nekatere strategije posredujejo možnosti odjemalca knjižnici OAuth, druge nastavijo povezavo HTTP pod njo. Možnost, ki jo sprejme ena strategija, samodejno ni skupna možnost OmniAuth.

Pustite, da URL-ji za avtorizacijo, žeton in povratni klic ponudnika opisujejo njegove dejanske storitve. Odhodni posredniški strežnik je transportna nastavitev za doseganje ponudnika, ne nadomestni naslov povratnega klica in ne polje, ki bi ga dodali parametrom zahteve OAuth.

Pri sledenju prijave označite zadnji dokončani korak. Prikazana prijavna stran ponudnika dokazuje, da je pot brskalnika delovala. Povratni klic, ki ga prejme Rails, dokazuje, da se je brskalnik vrnil. Naslednja zahteva za žeton je mesto za preverjanje povezave prek posredniškega strežnika, izziva ali odgovora ponudnika iz procesa Rails.

Sorodni članki