OmniAuth መግቢያን በፕሮክሲ በኩል መከታተል

ተጠቃሚው “ግባ” የሚለውን በመጫን ወደ አቅራቢው ገጽ ይደርሳል፣ ከዚያም ወደ Rails ይመለሳል። ቀጣዩ ደረጃ ግን አሁንም ሊወድቅ ይችላል፣ ምክንያቱም ከRails አገልጋይ አዲስ ግንኙነት ስለሚጀምር።

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

አሳሹ የፈቃድ መሄጃውን በራሱ የኔትወርክ ውቅር ይከተላል። Rails ደግሞ በተጫነው የOmniAuth ስልት የተመረጠውን የHTTP ደንበኛ ተጠቅሞ የኋላ ቻናል ቶከን ልውውጡን ያከናውናል። በኮርፖሬት ፕሮክሲ ጀርባ የሚሠራ ሰራተኛ ለአቅራቢው ጥያቄዎች ይህንን መንገድ ይፈልጋል።

OAuth 1.0 ተጠቃሚው ፈቃድ ከመስጠቱ በፊት በአገልጋይ በኩል የሚደረግ የጥያቄ-ቶከን ደረጃም አለው። የOAuth 2.0 የፈቃድ-ኮድ ፍሰት ከመመለሻ በኋላ የራሱ የቶከን ልውውጥ አለው። ትክክለኛው ቅደም ተከተል በስልቱ ላይ ይወሰናል፣ ነገር ግን አሳሹና የመተግበሪያው አገልጋይ የተለያዩ መነሻ ነጥቦች ሆነው ይቆያሉ።

የደንበኛውን ውቅር ይፈልጉ

ስልቱን ተከትለው ቶከኑንና የአቅራቢውን የAPI ጥያቄዎች ወደሚልከው HTTP ደንበኛ ይሂዱ። የዚያ ደንበኛ በሰነድ የተገለጸውን የፕሮክሲ አማራጭ ይጠቀሙ። አንዳንድ ስልቶች የደንበኛ አማራጮችን ለOAuth ቤተ-መጽሐፍት ያስተላልፋሉ፤ ሌሎች ደግሞ ከሱ በታች የHTTP ግንኙነት ያዋቅራሉ። አንድ ስልት የሚቀበለው አማራጭ በራስ-ሰር የጋራ የOmniAuth አማራጭ አይሆንም።

የአቅራቢው የፈቃድ፣ የቶከንና የመመለሻ አድራሻዎች ትክክለኛ አገልግሎቶቻቸውን እንዲገልጹ ያቆዩ። ወደ ውጭ የሚወጣው ፕሮክሲ አቅራቢውን ለመድረስ የሚያገለግል የትራንስፖርት ቅንብር ነው፣ የመመለሻ አድራሻ ምትክ ወይም በOAuth የጥያቄ መለኪያዎች ውስጥ የሚጨመር መስክ አይደለም።

የመግቢያ ሂደትን ሲከታተሉ የመጨረሻውን የተጠናቀቀ ደረጃ ምልክት ያድርጉ። የታየ የአቅራቢ መግቢያ ገጽ የአሳሹ መንገድ እንደሠራ ያረጋግጣል። Rails የተቀበለው መመለሻ አሳሹ እንደተመለሰ ያሳያል። ቀጣዩ የቶከን ጥያቄ ከRails ሂደት የመጣ የፕሮክሲ ግንኙነት፣ የመረጋገጫ ጥያቄ ወይም የአቅራቢ ምላሽ መኖሩን መመርመሪያ ቦታ ነው።