OmniAuth prisijungimo stebėjimas per tarpinį serverį

Vartotojas paspaudžia „Prisijungti“, patenka į teikėjo puslapį ir grįžta į „Rails“. Kitas žingsnis vis tiek gali nepavykti, nes jis atidaro naują ryšį iš „Rails“ serverio.

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

Naršyklė vykdo autorizacijos nukreipimą pagal savo tinklo konfigūraciją. „Rails“ atlieka prieigos rakto mainus grįžtamuoju kanalu su HTTP klientu, kurį pasirenka įdiegta „OmniAuth“ strategija. Už įmonės tarpinio serverio veikiantis darbuotojas savo užklausose teikėjui turi turėti šį maršrutą.

„OAuth 1.0“ taip pat turi serverio pusės užklausos rakto žingsnį prieš vartotojui suteikiant prieigą. „OAuth 2.0“ autorizacijos kodo srautas turi savo prieigos rakto mainus po atgalinio iškvietimo. Tiksli seka priklauso nuo strategijos, bet naršyklė ir programos serveris išlieka skirtingi pradžios taškai.

Raskite kliento konfigūraciją

Sekite strategiją iki HTTP kliento, kuris siunčia jos prieigos raktą ir teikėjo API užklausas. Naudokite dokumentuotą to kliento tarpinio serverio parinktį. Kai kurios strategijos perduoda kliento parinktis „OAuth“ bibliotekai; kitos sukonfigūruoja HTTP ryšį po ja. Vienos strategijos priimama parinktis automatiškai netampa bendra „OmniAuth“ parinktimi.

Leiskite teikėjo autorizacijos, prieigos rakto ir atgalinio iškvietimo URL apibūdinti tikrąsias jo paslaugas. Išeinantis tarpinis serveris yra transporto nustatymas teikėjui pasiekti, o ne pakaitinis atgalinio iškvietimo adresas ir ne laukas, pridedamas prie „OAuth“ užklausos parametrų.

Stebėdami prisijungimą pažymėkite paskutinį užbaigtą žingsnį. Parodytas teikėjo prisijungimo puslapis įrodo, kad naršyklės maršrutas veikė. „Rails“ gautas atgalinis iškvietimas įrodo, kad naršyklė grįžo. Tolesnė prieigos rakto užklausa yra vieta, kur reikia tikrinti tarpinio serverio ryšį, iššūkį ar teikėjo atsakymą iš „Rails“ proceso.