Spuri OmniAuth-ensaluti tra prokura servilo

Uzanto alklakas “Ensaluti”, alvenas al la paĝo de la provizanto kaj revenas al Rails. La sekva paŝo ankoraŭ povas malsukcesi, ĉar ĝi malfermas novan konekton de la Rails-servilo.

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

La retumilo sekvas la rajtigan plusendadon per sia propra reta agordo. Rails faras la ĵetan interŝanĝon sur la malantaŭa kanalo per la HTTP-kliento elektita de la instalita OmniAuth-strategio. Laboranto malantaŭ entreprena prokura servilo bezonas tiun vojon por siaj petoj al la provizanto.

Ankaŭ OAuth 1.0 havas serviloflankan paŝon pri petĵetono antaŭ ol la uzanto rajtigas aliron. La rajtigkoda fluo de OAuth 2.0 havas propran ĵetan interŝanĝon post la revokado. La preciza sinsekvo dependas de la strategio, sed la retumilo kaj la aplikaĵservilo restas apartaj elirpunktoj.

Trovu la agordon de la kliento

Sekvu la strategion ĝis la HTTP-kliento, kiu sendas ĝian ĵetonon kaj la petojn al la API de la provizanto. Uzu la dokumentitan prokuran opcion de tiu kliento. Kelkaj strategioj transdonas klientajn opciojn al OAuth-biblioteko; aliaj agordas HTTP-konekton sub ĝi. Opcio akceptata de unu strategio ne aŭtomate estas komuna OmniAuth-opcio.

Lasu la rajtigajn, ĵetajn kaj revokajn URL-ojn de la provizanto priskribi ĝiajn realajn servojn. La elira prokura servilo estas transporta agordo por atingi la provizanton, ne anstataŭa revoka adreso nek kampo aldonenda al la parametroj de la OAuth-peto.

Kiam vi spuras ensaluton, marku la lastan plenumitan paŝon. Montrita ensaluta paĝo de la provizanto pruvas, ke la vojo de la retumilo funkciis. Revoko ricevita de Rails pruvas, ke la retumilo revenis. La sekva ĵeta peto estas la loko por kontroli prokuran konekton, defion aŭ respondon de la provizanto el la Rails-procezo.