In OmniAuth-oanmelding troch in proxy folgje

In brûker klikt op “Oanmelde”, berikt de side fan 'e oanbieder en giet werom nei Rails. De folgjende stap kin dochs mislearje, om't er in nije ferbining fan 'e Rails-tsjinner ôf begjint.

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

De browser folget de autorisaasjetrochferwizing mei syn eigen netwurkkonfiguraasje. Rails docht de tokenútwikseling oer it efterkanaal mei de HTTP-klant dy't de ynstalleare OmniAuth-strategy kiest. In worker efter in bedriuwsproxy hat dy rûte nedich by syn oanfragen oan 'e oanbieder.

OAuth 1.0 hat ek in stap foar oanfraachtoken oan 'e tsjinnerkant foardat de brûker tagong autorisearret. De autorisaasjekoade-flow fan OAuth 2.0 hat syn eigen tokenútwikseling nei de callback. De krekte folchoarder hinget fan 'e strategy ôf, mar de browser en de applikaasjetsjinner bliuwe aparte begjinpunten.

Fyn de konfiguraasje fan 'e klant

Folgje de strategy nei de HTTP-klant dy't syn token en de API-oanfragen fan 'e oanbieder stjoert. Brûk de dokumintearre proxy-opsje fan dy klant. Guon strategyen jouwe klantopsjes troch oan in OAuth-bibleteek; oaren konfigurearje in HTTP-ferbining dêrûnder. In opsje dy't ien strategy akseptearret, is net automatysk in mienskiplike OmniAuth-opsje.

Lit de autorisaasje-, token- en callback-URL's fan 'e oanbieder syn echte tsjinsten beskriuwe. De útgeande proxy is in ferfiersynstelling om de oanbieder te berikken, net in ferfangend callback-adres en net in fjild dat oan 'e OAuth-oanfraachparameters tafoege wurdt.

As jo in oanmelding folgje, markearje dan de lêst foltôge stap. In toande oanmeldside fan 'e oanbieder bewiist dat de rûte fan 'e browser wurke. In callback dy't Rails ûntfangt, bewiist dat de browser weromkaam. De folgjende tokenoanfraach is it plak om te kontrolearjen op in proxyferbining, in útdaging of in antwurd fan 'e oanbieder út it Rails-proses.