प्रॉक्सीद्वारे 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 पर्याय होत नाही.

प्रदात्याचे अधिकृतता, टोकन आणि कॉलबॅक URL त्याच्या खऱ्या सेवांचे वर्णन करत राहू द्या. आउटबाउंड प्रॉक्सी प्रदात्यापर्यंत पोहोचण्यासाठीचे वाहतूक सेटिंग आहे, तो कॉलबॅक पत्त्याचा पर्याय नाही किंवा OAuth विनंतीच्या पॅरामीटर्समध्ये जोडायचे क्षेत्र नाही.

लॉगिनचा मागोवा घेताना शेवटची पूर्ण झालेली पायरी चिन्हांकित करा. प्रदात्याचे लॉगिन पान दिसले तर ब्राउझरचा मार्ग चालला हे सिद्ध होते. Rails ला मिळालेला कॉलबॅक ब्राउझर परत आला हे सिद्ध करतो. त्यानंतरची टोकन विनंती म्हणजे Rails प्रक्रियेतून येणारे प्रॉक्सी कनेक्शन, आव्हान किंवा प्रदात्याचा प्रतिसाद तपासण्याची जागा.