מעקב אחר התחברות 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 יש החלפת אסימון משלה לאחר ה-callback. הרצף המדויק תלוי באסטרטגיה, אבל הדפדפן ושרת האפליקציה נשארים נקודות התחלה נפרדות.

איתור תצורת הלקוח

עקבו אחר האסטרטגיה עד לקוח ה-HTTP ששולח את האסימון שלה ואת בקשות ה-API אל הספק. השתמשו באפשרות הפרוקסי המתועדת של אותו לקוח. אסטרטגיות מסוימות מעבירות אפשרויות לקוח לספריית OAuth; אחרות מגדירות חיבור HTTP מתחתיה. אפשרות שאסטרטגיה אחת מקבלת אינה אפשרות OmniAuth משותפת באופן אוטומטי.

השאירו את כתובות ההרשאה, האסימון וה-callback של הספק כמתארות את השירותים האמיתיים שלו. הפרוקסי היוצא הוא הגדרת תעבורה להגעה אל הספק, לא כתובת callback חלופית ולא שדה שמוסיפים לפרמטרים של בקשת OAuth.

כשאתם עוקבים אחר התחברות, סמנו את השלב האחרון שהושלם. עמוד התחברות מוצג של הספק מוכיח שהמסלול של הדפדפן עבד. callback שמתקבל ב-Rails מוכיח שהדפדפן חזר. בקשת האסימון שלאחר מכן היא המקום לבדוק חיבור פרוקסי, אתגר או תגובה מהספק מצד תהליך ה-Rails.