OmniAuth-kirjautumisen jäljittäminen välityspalvelimen kautta

Käyttäjä napsauttaa ”Kirjaudu sisään”, saapuu tarjoajan sivulle ja palaa Railsiin. Seuraava vaihe voi silti epäonnistua, koska se avaa uuden yhteyden Rails-palvelimelta.

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

Selain seuraa valtuutuksen uudelleenohjausta omalla verkkokokoonpanollaan. Rails tekee taustakanavan token-vaihdon HTTP-asiakkaalla, jonka asennettu OmniAuth-strategia valitsee. Yrityksen välityspalvelimen takana toimiva työntekijä tarvitsee kyseisen reitin tarjoajalle lähtevissä pyynnöissään.

Myös OAuth 1.0:ssa on palvelinpuolen pyyntötoken-vaihe ennen kuin käyttäjä valtuuttaa pääsyn. OAuth 2.0:n valtuutuskoodivuo tekee oman token-vaihtonsa paluukutsun jälkeen. Tarkka järjestys riippuu strategiasta, mutta selain ja sovelluspalvelin pysyvät erillisinä lähtökohtina.

Etsi asiakkaan kokoonpano

Seuraa strategiaa HTTP-asiakkaaseen, joka lähettää sen tokenin ja tarjoajan API-pyynnöt. Käytä kyseisen asiakkaan dokumentoitua välityspalvelinasetusta. Jotkin strategiat välittävät asiakasasetukset OAuth-kirjastolle; toiset määrittävät HTTP-yhteyden sen alle. Yhden strategian hyväksymä asetus ei ole automaattisesti yhteinen OmniAuth-asetus.

Anna tarjoajan valtuutus-, token- ja paluukutsu-URL-osoitteiden kuvata sen todellisia palveluja. Lähtevä välityspalvelin on kuljetusasetus tarjoajan tavoittamiseen, ei korvaava paluukutsun osoite eikä OAuth-pyynnön parametreihin lisättävä kenttä.

Kun jäljität kirjautumista, merkitse viimeksi suoritettu vaihe. Näytetty tarjoajan kirjautumissivu osoittaa, että selaimen reitti toimi. Railsin vastaanottama paluukutsu osoittaa, että selain palasi. Seuraava token-pyyntö on paikka, josta tarkistetaan Rails-prosessista tuleva välityspalvelinyhteys, haaste tai tarjoajan vastaus.