پروکسی کے ذریعے 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 اختیار نہیں ہوتا۔

فراہم کنندہ کے اجازت، ٹوکن اور کال بیک URLs کو اُس کی حقیقی خدمات بیان کرنے دیں۔ آؤٹ باؤنڈ پروکسی فراہم کنندہ تک پہنچنے کی ٹرانسپورٹ ترتیب ہے، یہ کال بیک پتے کا متبادل نہیں اور نہ ہی OAuth درخواست کے پیرامیٹرز میں شامل کرنے والی فیلڈ ہے۔

لاگ اِن کی پیروی کرتے وقت آخری مکمل شدہ مرحلہ نشان زد کریں۔ فراہم کنندہ کا دکھایا گیا لاگ اِن صفحہ ثابت کرتا ہے کہ براؤزر کا راستہ کام کر گیا۔ Rails کا موصول کردہ کال بیک ثابت کرتا ہے کہ براؤزر واپس آیا۔ اگلی ٹوکن درخواست ہی وہ جگہ ہے جہاں Rails کے عمل سے آنے والے پروکسی کنکشن، چیلنج یا فراہم کنندہ کے جواب کا جائزہ لینا چاہیے۔