प्रोक्सीमार्फत 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 प्रक्रियाबाट आउने प्रोक्सी जडान, चुनौती वा प्रदायकको प्रतिक्रिया जाँच्ने ठाउँ हो।