Een OmniAuth-login volgen via een proxy

De gebruiker klikt op ‘Inloggen’, bereikt de pagina van de provider en keert terug naar Rails. De volgende stap kan alsnog mislukken, omdat die een nieuwe verbinding vanaf de Rails-server opent.

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

De browser volgt de autorisatieomleiding met zijn eigen netwerkconfiguratie. Rails doet de tokenuitwisseling op het terugkanaal met de HTTP-client die de geïnstalleerde OmniAuth-strategie kiest. Een worker achter een bedrijfsproxy heeft die route nodig op zijn aanvragen naar de provider.

OAuth 1.0 heeft ook een stap voor een aanvraagtoken aan de serverkant voordat de gebruiker toegang autoriseert. De autorisatiecodeflow van OAuth 2.0 heeft zijn eigen tokenuitwisseling na de callback. De exacte volgorde hangt van de strategie af, maar de browser en de applicatieserver blijven aparte uitgangspunten.

De configuratie van de client vinden

Volg de strategie tot de HTTP-client die het token en de API-aanvragen naar de provider stuurt. Gebruik de gedocumenteerde proxyoptie van die client. Sommige strategieën geven clientopties door aan een OAuth-bibliotheek; andere configureren een HTTP-verbinding eronder. Een optie die één strategie accepteert, is niet automatisch een gedeelde OmniAuth-optie.

Laat de autorisatie-, token- en callback-URL's van de provider de werkelijke diensten beschrijven. De uitgaande proxy is een transportinstelling om de provider te bereiken, geen vervangend callbackadres en geen veld dat aan de OAuth-aanvraagparameters wordt toegevoegd.

Markeer bij het volgen van een login de laatst voltooide stap. Een getoonde inlogpagina van de provider bewijst dat de route van de browser werkte. Een callback die Rails ontvangt, bewijst dat de browser terugkeerde. De daaropvolgende tokenaanvraag is de plek om te controleren op een proxyverbinding, een uitdaging of een providerantwoord vanuit het Rails-proces.