אני מקווה לקבל כמה עיניים מומחיות על בעיות שאני נתקל בהן תוך כדי ניסיון להשתמש ב-Discourse כספק SSO.
המטרה שלי: אני מגדיר את Discourse לטפל באימות עבור יישום אחר (LibreChat). אני משתמש בפונקציונליות הסטנדרטית של ספק DiscourseConnect, כאשר שירות הגשר distrust OIDC פועל כלקוח שמתקשר עם Discourse.
הבעיה: זרימת ה-SSO עובדת בצורה מושלמת עד השלב האחרון. המשתמש מופנה כראוי מהאפליקציה שלי ל-Discourse, והוא יכול להתחבר בהצלחה באמצעות פרטי ההתחברות שלו ל-Discourse. עם זאת, לאחר ההתחברות, הוא מופנה חזרה לדף הבית של פורום ה-Discourse שלי (/) במקום ל-return_sso_url שסופק.
היכן אני תקוע (מה שללתי): עבדתי על פתרון הבעיה הזו זמן מה ואישרתי שזו לא שגיאת תצורה פשוטה. שללתי באופן מוחלט את הדברים הבאים:
- סודות:
סודות ספק ה-Discourse Connectמוגדרים כראוי. אני משתמש בדומיין הפשוט (למשל,auth.my-site.com) ללא כל פרוטוקול, ומפתח הסוד תואם באופן מושלם לזה שבשירות הלקוח שלי. - מצב SSO: אישרתי ש-
enable discourse connect providerמסומן, והגדרות “SSO Client” השגויות מושבתות. - מדיניות משתמשים: דאגתי ש-
must_approve_usersיהיה מושבת, ומשתמש הבדיקה שלי הוא מנהל מערכת עם אימייל מאומת במלואו. - תוספים: השבתתי את כל התוספים של צד שלישי שאינם רשמיים ובניתי מחדש את הקונטיינר, אך הבעיה נמשכת.
הראיות המרכזיות: יש לי שני ממצאים מכריעים שמשאירים אותי מבולבל:
- ניתוח קובץ HAR: לכדתי את כל זרימת הרשת בקובץ HAR. הוא מראה שהבקשה
POSTל-/sessionלצורך התחברות מצליחה. השרת מגיב מיד עם הפניה מחדש מסוג302 Found, אך כותרת ה-Locationהיא באופן עקבי/. זה מוכיח ש-Discourse מבטל בכוונה את הפניית ה-SSO. - יומן Rails ריק: לאחר מכן עקבתי אחר קובץ
production.logבתוך הקונטיינר בזמן שניסיתי להתחבר. שום דבר לא נכתב ליומן במהלך תהליך זה. זה אומר לי ש-Discourse לא רואה בזה שגיאה; זו פעולה מכוונת ושקטה.
השאלה שלי: בהתחשב בכך שההתחברות מצליחה, אך ההפניה מחדש שגויה ואין שגיאות ביומנים, איזו מדיניות פנימית של Discourse, בדיקת טרום-טיסה, או הגדרה נסתרת יכולה לגרום לה להתעלם מה-return_sso_url ולהפנות לדף הבית במקום? אני מרגיש שמיציתי את כל ההגדרות הסטנדרטיות.
תודה מראש על כל רעיון!