تتبّع تسجيل الدخول عبر 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 الذي يرسل رمزها وطلبات واجهة برمجة المزوّد. استخدم خيار الوسيط الموثّق لذلك العميل. بعض الاستراتيجيات تمرّر خيارات العميل إلى مكتبة OAuth، وأخرى تهيّئ اتصال HTTP تحتها. والخيار الذي تقبله استراتيجية واحدة ليس خيارًا مشتركًا في OmniAuth تلقائيًا.

أبقِ عناوين التفويض والرمز ورد النداء للمزوّد معبّرة عن خدماتها الفعلية. فالوسيط الصادر إعداد نقل يُستخدم للوصول إلى المزوّد، وليس عنوان رد نداء بديلًا ولا حقلًا يُضاف إلى معاملات طلب OAuth.

عند تتبّع تسجيل الدخول، حدّد آخر خطوة مكتملة. ظهور صفحة دخول المزوّد يثبت أن مسار المتصفح نجح. ووصول رد النداء إلى Rails يثبت أن المتصفح عاد. أما طلب الرمز اللاحق فهو موضع فحص اتصال الوسيط أو التحدي أو استجابة المزوّد من عملية Rails.