OmniAuth մուտքի հետևում պրոքսիի միջոցով

Օգտատերը սեղմում է «Մուտք», հասնում մատակարարի էջին և վերադառնում Rails։ Հաջորդ քայլը դեռ կարող է ձախողվել, քանի որ այն նոր կապ է բացում Rails սերվերից։

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

Զննարկիչը հետևում է լիազորման վերահասցեավորմանը իր սեփական ցանցային կարգավորումներով։ Rails-ը կատարում է թոքենի փոխանակումը հետին ալիքով այն HTTP հաճախորդով, որը ընտրել է տեղադրված OmniAuth ռազմավարությունը։ Կորպորատիվ պրոքսիի հետևում աշխատող վորքերին այդ ուղին անհրաժեշտ է մատակարարին ուղղված հարցումներում։

OAuth 1.0-ն նույնպես ունի սերվերի կողմի հարցում-թոքենի քայլ, նախքան օգտատերը կլիազորի հասանելիությունը։ OAuth 2.0-ի լիազորման կոդի հոսքը հետադարձ կանչից հետո ունի իր թոքենի փոխանակումը։ Ճշգրիտ հաջորդականությունը կախված է ռազմավարությունից, բայց զննարկիչը և հավելվածի սերվերը մնում են տարբեր մեկնարկային կետեր։

Գտեք հաճախորդի կարգավորումները

Հետևեք ռազմավարությանը մինչև այն HTTP հաճախորդը, որը ուղարկում է նրա թոքենը և մատակարարի API հարցումները։ Օգտագործեք այդ հաճախորդի փաստաթղթավորված պրոքսի տարբերակը։ Որոշ ռազմավարություններ հաճախորդի պարամետրերը փոխանցում են OAuth գրադարանին, մյուսները դրա տակ կարգավորում են HTTP կապ։ Մի ռազմավարության ընդունած տարբերակը ինքնաբերաբար OmniAuth-ի ընդհանուր տարբերակ չէ։

Թող մատակարարի լիազորման, թոքենի և հետադարձ կանչի URL-ները նկարագրեն նրա իրական ծառայությունները։ Ելքային պրոքսին մատակարարին հասնելու տրանսպորտային կարգավորում է, ոչ թե փոխարինող հետադարձ հասցե կամ OAuth հարցման պարամետրերին ավելացվող դաշտ։

Մուտքը հետևելիս նշեք վերջին ավարտված քայլը։ Ցուցադրված մատակարարի մուտքի էջը ապացուցում է, որ զննարկիչի ուղին աշխատել է։ Rails-ի ստացած հետադարձ կանչը ապացուցում է, որ զննարկիչը վերադարձել է։ Հաջորդ թոքենի հարցումն այն տեղն է, որտեղ պետք է ստուգել պրոքսի կապը, մարտահրավերը կամ մատակարարի պատասխանը Rails գործընթացից։