ردیابی ورود 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 نیست.

بگذارید نشانی‌های مجوز، توکن و بازگشت فراخوانی ارائه‌دهنده همان سرویس‌های واقعی آن را توصیف کنند. پروکسی خروجی یک تنظیم انتقال برای رسیدن به ارائه‌دهنده است، نه نشانی بازگشتی جایگزین و نه فیلدی که به پارامترهای درخواست OAuth افزوده شود.

هنگام ردیابی ورود، آخرین مرحلهٔ کامل‌شده را علامت بزنید. نمایش صفحهٔ ورود ارائه‌دهنده ثابت می‌کند مسیر مرورگر کار کرده است. دریافت بازگشت فراخوانی در Rails ثابت می‌کند مرورگر بازگشته است. درخواست توکن بعدی همان جایی است که باید اتصال پروکسی، چالش یا پاسخ ارائه‌دهنده از فرایند Rails را بررسی کرد.