Sporing av ei OmniAuth-innlogging gjennom ein proxy

Brukaren klikkar på «Logg inn», når sida til leverandøren og kjem tilbake til Rails. Det neste steget kan likevel mislukkast fordi det opnar ei ny tilkopling frå Rails-tenaren.

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

Nettlesaren følgjer autorisasjonsomdirigeringa med si eiga nettverksoppsett. Rails utfører tokenutvekslinga på bakkanalen med HTTP-klienten som den installerte OmniAuth-strategien vel. Ein arbeidsprosess bak ein bedriftsproxy treng den ruta på førespurnadene til leverandøren.

OAuth 1.0 har òg eit steg med førespurnadstoken på tenarsida før brukaren autoriserer tilgang. Autorisasjonskodeflyten i OAuth 2.0 har si eiga tokenutveksling etter callbacken. Den nøyaktige rekkjefølgja er avhengig av strategien, men nettlesaren og applikasjons-tenaren er framleis ulike utgangspunkt.

Finn oppsettet til klienten

Følg strategien til HTTP-klienten som sender tokenet og førespurnadene til API-et til leverandøren. Bruk den dokumenterte proxyinnstillinga til den klienten. Nokre strategiar sender klientinnstillingar vidare til eit OAuth-bibliotek; andre set opp ei HTTP-tilkopling under det. Ei innstilling som éin strategi godtek, er ikkje automatisk ei felles OmniAuth-innstilling.

Lat autorisasjons-, token- og callback-URL-ane til leverandøren skildre dei verkelege tenestene hans. Utgåande proxy er ei transportinnstilling for å nå leverandøren, ikkje ei erstatningsadresse for callback og ikkje eit felt som blir lagt til OAuth-førespurnadsparametrane.

Når du sporer ei innlogging, merk det sist fullførte steget. Ei vist innloggingsside hos leverandøren provar at ruta til nettlesaren virka. Ein callback som Rails tek imot, provar at nettlesaren kom tilbake. Den påfølgjande tokenførespurnaden er staden å undersøkje for ei proxykopling, ei utfordring eller eit svar frå leverandøren frå Rails-prosessen.