OmniAuth-aanmelding deur 'n proxy volg

’n Gebruiker klik op “Meld aan”, bereik die verskaffer se bladsy en keer terug na Rails. Die volgende stap kan steeds misluk, want dit begin ’n nuwe verbinding vanaf die Rails-bediener.

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

Die blaaier volg die magtigingsherleiding met sy eie netwerkkonfigurasie. Rails doen die agterkanaal-tokenuitruiling met die HTTP-kliënt wat deur die geïnstalleerde OmniAuth-strategie gekies is. ’n Werker wat agter ’n korporatiewe proxy loop, het daardie roete nodig vir sy versoeke aan die verskaffer.

OAuth 1.0 het ook ’n bedienerkant-stap vir die aanvraagtoken voordat die gebruiker toegang magtig. OAuth 2.0 se magtigingskode-vloei het sy eie tokenuitruiling ná die terugbel. Die presiese volgorde hang van die strategie af, maar die blaaier en die toepassingbediener bly aparte beginpunte.

Vind die kliënt se konfigurasie

Volg die strategie na die HTTP-kliënt wat sy token- en verskaffer-API-versoeke stuur. Gebruik daardie kliënt se gedokumenteerde proxy-opsie. Sommige strategieë gee kliëntopsies aan ’n OAuth-biblioteek; ander stel ’n HTTP-verbinding daaronder op. ’n Opsie wat een strategie aanvaar, is nie outomaties ’n gedeelde OmniAuth-opsie nie.

Hou die verskaffer se magtigings-, token- en terugbel-URL’s by wat hulle werklik dien. Die uitgaande proxy is ’n vervoerinstelling om die verskaffer te bereik, nie ’n vervangende terugbeladres of ’n veld om by die OAuth-versoekparameters te voeg nie.

Merk die laaste voltooide stap wanneer jy ’n aanmelding volg. ’n Weergegewe verskaffer-aanmeldbladsy bevestig dat die blaaier se roete gewerk het. ’n Terugbel wat Rails ontvang, bevestig dat die blaaier teruggekeer het. Die daaropvolgende tokenversoek is die plek om te ondersoek vir ’n proxyverbinding, -uitdaging of verskafferantwoord vanaf die Rails-proses.