Spore en OmniAuth-pålogging gjennom en proxy

Brukeren klikker på «Logg inn», når leverandørens side og kommer tilbake til Rails. Neste trinn kan likevel feile fordi det åpner en ny tilkobling fra Rails-serveren.

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

Nettleseren følger autorisasjonsomdirigeringen med sin egen nettverkskonfigurasjon. Rails utfører tokenutvekslingen på bakkanalen med HTTP-klienten som den installerte OmniAuth-strategien velger. En arbeidsprosess bak en bedriftsproxy trenger den ruten på forespørslene til leverandøren.

OAuth 1.0 har også et trinn med forespørselstoken på serversiden før brukeren autoriserer tilgang. Autorisasjonskodeflyten i OAuth 2.0 har sin egen tokenutveksling etter callbacken. Den nøyaktige rekkefølgen avhenger av strategien, men nettleseren og applikasjonsserveren forblir forskjellige utgangspunkter.

Finn klientens konfigurasjon

Følg strategien til HTTP-klienten som sender tokenet og forespørslene til leverandørens API. Bruk den dokumenterte proxyinnstillingen til den klienten. Noen strategier sender klientinnstillinger videre til et OAuth-bibliotek; andre konfigurerer en HTTP-tilkobling under det. En innstilling som én strategi godtar, er ikke automatisk en felles OmniAuth-innstilling.

La leverandørens autorisasjons-, token- og callback-URL-er beskrive de faktiske tjenestene. Den utgående proxyen er en transportinnstilling for å nå leverandøren, ikke en erstatningsadresse for callback og ikke et felt som legges til OAuth-forespørselens parametere.

Når du sporer en pålogging, merk det sist fullførte trinnet. En vist påloggingsside hos leverandøren beviser at nettleserens rute fungerte. En callback som Rails mottar, beviser at nettleseren kom tilbake. Den påfølgende tokenforespørselen er stedet å undersøke for en proxyforbindelse, en utfordring eller et svar fra leverandøren fra Rails-prosessen.