प्रॉक्सी के माध्यम से 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 के प्राधिकरण-कोड प्रवाह में कॉलबैक के बाद अपना टोकन एक्सचेंज होता है। सटीक क्रम रणनीति पर निर्भर करता है, पर ब्राउज़र और एप्लिकेशन सर्वर अलग-अलग प्रारंभ बिंदु बने रहते हैं।

क्लाइंट का कॉन्फ़िगरेशन खोजें

रणनीति का पालन उस HTTP क्लाइंट तक करें जो उसका टोकन और प्रदाता API अनुरोध भेजता है। उस क्लाइंट के प्रलेखित प्रॉक्सी विकल्प का उपयोग करें। कुछ रणनीतियाँ क्लाइंट विकल्प OAuth लाइब्रेरी को देती हैं; अन्य उसके नीचे HTTP कनेक्शन कॉन्फ़िगर करती हैं। एक रणनीति द्वारा स्वीकार किया गया विकल्प स्वतः साझा OmniAuth विकल्प नहीं होता।

प्रदाता के प्राधिकरण, टोकन और कॉलबैक URL को उसकी वास्तविक सेवाओं का वर्णन करने दें। आउटबाउंड प्रॉक्सी प्रदाता तक पहुँचने के लिए परिवहन सेटिंग है, न कि कॉलबैक पते का विकल्प और न ही OAuth अनुरोध मापदंडों में जोड़ने योग्य फ़ील्ड।

लॉगिन का पता लगाते समय अंतिम पूर्ण हुए चरण को चिह्नित करें। दिखाया गया प्रदाता लॉगिन पृष्ठ सिद्ध करता है कि ब्राउज़र का मार्ग काम कर गया। Rails को मिला कॉलबैक सिद्ध करता है कि ब्राउज़र लौट आया। उसके बाद का टोकन अनुरोध वह स्थान है जहाँ Rails प्रक्रिया से आने वाले प्रॉक्सी कनेक्शन, चुनौती या प्रदाता प्रतिक्रिया की जाँच करनी चाहिए।