ساعدني في استكشاف مشكلة SSO الخاصة بـ Discourse

[sda]

مرحبًا، آمل الحصول على بعض التوجيه. توقف نظام تسجيل الدخول الموحد (SSO) الخاص بي عن العمل هذا الأسبوع، وظننت أنني أصلحت كل شيء أمس (كان يعمل، أقسم ملاحظة: لقد تفحصت قائمة “المستخدمين الجدد” من الأمس واليوم، وكان لدي مستخدمون جدد في كلا اليومين (بعد إصلاحه)، والآن تعطل مرة أخرى…). للأسف، التحديثات التي أجريتها لا تعمل اليوم.

المشكلة: لا يستطيع المستخدمون إنشاء حسابات جديدة، ولا يمكن للمستخدمين الذين قاموا بتسجيل الخروج الدخول مرة أخرى.

لاحظت أن خادم Discourse الخاص بي يعطي أخطاء 400 في المسارات التالية:

403: GET: discourse-url/users/by-external/USER-ID.json?
ملاحظة: لقد اكتشفت مؤخرًا في وثائق API أن هذا المسار غير موجود؟ (على الرغم من أنه كان يعمل)، ويبدو أن المسار الصحيح هو: https://discourse.example.com/u/by-external/{external_id}.json

404: POST: discourse-url/admin/users/sync_sso?

السبب في وجود علامة الاستفهام ? في النهاية هو أن لدي حقلًا اختياريًا للمعاملات في دالة تقوم بتوليد الروابط، وفي هذين المسارين تُرسل جميع البيانات في جسم النموذج أو في الرؤوس.

أنا أستخدم المكتبة التالية.

ما قمت بتحديثه (وما اعتقدت أنه أصلح المشكلة):

في جميع طلباتي، كنت أرسل Api-Key و Api-Username كمعاملات في الرابط (query parameters). خلال الأشهر القليلة الماضية، لاحظت في لوحة التحكم الخاصة بي تحذيرًا مفاده أنني أستخدم رؤوسًا قديمة في طلباتي. أرشدني هذا التحذير إلى هذا المنشور، وإليك التفاصيل الرئيسية:

تحذير بشأن الإيقاف التدريجي!
في 6 أبريل 2020، ألغينا دعم جميع طرق المصادقة غير المعتمدة على رؤوس HTTP (باستثناء بعض مسارات RSS، واستقبال البريد، وICS). وهذا يعني أن طلبات API التي تحتوي على api_key و api_username في معاملات الرابط أو في جسم طلب HTTP ستتوقف قريبًا عن العمل. يرجى الاطلاع على مثال طلب cURL أدناه لمعرفة كيفية تحديث طلبات API الخاصة بك لاستخدام رؤوس HTTP للمصادقة.

لقد قمت بتحديث جميع طلباتي، والآن تحتوي جميعها على Api-Key و Api-Username في الرأس، وتم تعيين نوع المحتوى إلى multipart form data.

إذا كان بإمكان أي شخص تقديم بعض التوجيه حول ما يجب البحث فيه لتصحيح هذه المشكلة، فسأكون ممتنًا جدًا. أنا واثق بنسبة 100% تقريبًا من أن هذا كان يعمل في نهاية يوم عمل أمس، حيث تمكنت من تسجيل الدخول والخروج من حسابي، كما تمكنت من إنشاء حسابات جديدة.

يرجى إخباري إذا كنت بحاجة إلى مزيد من المعلومات. شكرًا!

[simon]

@sda

لقد قمت بتحديث جميع طلباتي، والآن تحتوي جميع الطلبات على api_key و api_username في الرأس، وتم تعيين نوع المحتوى إلى multipart form data.

يجب أن تستخدم حقول الرأس شرطات (-) بدلاً من الشرطات السفلية (_). جرب تغيير أسماء الحقول إلى Api-Key و Api-Username.

لا أعرف ما إذا كان هذا سيحل مشكلة عدم قدرة المستخدمين على تسجيل الدخول إلى موقعك، لكنه سيحل مشكلة أخطاء 400 التي تواجهها.

[sda]

@simon، شكرًا لك على الرد! للأسف، لم أوثق منشوري بشكل جيد، فأنا أستخدم بالفعل - وليس _ في طلباتي.

[simon]

لبدء تصحيح هذا الخطأ، انتقل إلى صفحة إعدادات موقع Discourse الخاص بك وابحث عن ‘sso’ للحصول على جميع إعدادات SSO الخاصة بك. تأكد من صحة إعدادات enable sso و sso url و sso secret. ثم قم بتفعيل إعداد الموقع verbose sso logging. عند تفعيل هذا الإعداد، سيتم إضافة بعض مدخلات السجل الإضافية إلى سجلات الأخطاء الخاصة بموقعك (الموجودة في Admin / Logs / Error Logs).

حاول تسجيل الدخول عبر SSO. ثم راجع سجلات الأخطاء الخاصة بك لمعرفة ما إذا كانت تقدم أي تفاصيل حول المشكلة. إذا لم تظهر لك أي معلومات مفيدة، افتح مفتش الويب في متصفحك وانتقل إلى تبويب Network مع تحديد مربع الاختيار “Preserve log”. راجع الطلبات التي يتم إجراؤها.

إذا أغلقت نفسك خارج موقعك أثناء محاولة إصلاح المشكلة، يمكنك كمستخدم مسؤول تجاوز SSO بالانتقال إلى /u/admin-login وإدخال عنوان بريدك الإلكتروني في النموذج. سيتم إرسال بريد إلكتروني إليك يحتوي على رابط تسجيل الدخول.

[sda]

@سيمون، شكرًا لك على النصيحة! لقد كنت أراجع السجلات، لكنني لست خبيرًا في قراءتها. أحصل على نوعين مختلفين من التحذيرات وخطأ واحد:

إليك التحذير الذي أواجهه بشكل متكرر:

Verbose SSO log: Started SSO process add_groups: admin: moderator: avatar_force_update: avatar_url: bio: card_background_url: email: external_id: groups: locale: locale_force_update: logo

إليك الخطأ:

Job exception: The difference between the request time and the current time is too large.

عند محاولة تسجيل الدخول كمستخدم تجريبي على موقعي الذي قمت بتسجيل الخروج منه من Discourse، يظهر لي ما يلي في لوحة الشبكة:

503 Service Unavailable: GET- https://my-site/auth/discourse_sso?sso=XXXX&sig=xxxx

للأسف، لقد وصلت إلى طريق مسدود ولا أعرف كيف أProceed من هنا.

[simon]

@sda، مشاركة: 5، موضوع: 155639

استثناء المهمة: الفرق بين وقت الطلب والوقت الحالي كبير جدًا.

أعتقد أن رسالة الخطأ هذه قادمة من Amazon S3. قد تكون هناك تفاصيل مفيدة حول كيفية حل المشكلة في هذا الموضوع: Backups have started failing due to server time being wrong. هناك المزيد من المعلومات هنا: https://stackoverflow.com/questions/4770635/s3-error-the-difference-between-the-request-time-and-the-current-time-is-too-la.

[sda]

@سيمون، شكرًا لك على المساعدة! كان وقت خادمي غير متزامن، وقمت بتحديثه، والآن تعمل النسخ الاحتياطية مرة أخرى!

الآن أواجه خطأً جديدًا بشكل متقطع:

في قسم السجلات، تظهر تحذيرات عشوائية (ظهرت لي مرتين فقط):

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-City.mmdb) could not be found: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-City.mmdb

و

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-ASN.mmdb) could not be found: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-ASN.mmdb

أنا أبحث حاليًا عن كيفية حل هذه المشكلة. لقد حاولت إعادة بناء التطبيق، لكنني لست متأكدًا بنسبة 100% من نجاح عملية إعادة البناء. ما زلت أواجه أخطاء MaxMindDB could not be found بشكل عشوائي، بالإضافة إلى أخطاء 400 و503 التي كنت أواجهها سابقًا.

[sda]

لقد عملت على هذا الأمر معظم ساعات الصباح الباكر دون تحقيق تقدم كبير. أعتقد أنني قضيت على أخطاء MaxMindDB (كانت تظهر بشكل متقطع وغير متسق سابقًا، ولم أتمكن من إعادة إنتاجها خلال الـ 3 ساعات الماضية)، وقد أعيدت بناء تطبيقي بنجاح عدة مرات.

إليك المكان الذي تتعطل فيه عملية SSO:

• يزور المستخدم Discourse
• نظرًا لعدم وجود جلسة نشطة، يتم إعادة توجيه المستخدم إلى discourse/session/sso_login
• يتم إعادة توجيه المستخدم إلى my-site/discourse_sso?sso=XXXX&sig=XXXX
• عند الوصول إلى المسار السابق من موقعي، أقوم بإرسال طلب GET إلى /users/by-external/userId.json
  • يعود هذا الطلب بـ 403 Forbidden
• مباشرة بعد ذلك، يُرسل طلب POST إلى /admin/users/sync_sso
  • وهذا ينتج عنه خطأ 404 "No route matches [POST] /admin/users/sync_sso
• في النهاية، يعيد موقعي رسالة خطأ 503 Forbidden (أحتاج إلى تنظيف بعض رسائل الخطأ في جانب موقعي)

أشعر أن الخطأ يقع على جانب تطبيق Rails (أرجو تصحيحني إذا كنت مخطئًا). والسبب في شعوري هذا هو أنه في نهاية يوم الجمعة، كان كل شيء يعمل بشكل صحيح، وهناك دليل على ذلك حيث قام عدد قليل من المستخدمين الجدد بالتسجيل بين مساء الجمعة وصباح السبت (وكان تسجيل الدخول أو إنشاء مستخدم جديد هو ما كان معطلاً). وكما ذكرت في منشورات سابقة، ظننت أنني أصلحت كل شيء، لكن عندما بدأت العمل في السبت، لاحظت أن المشكلة عادت مرة أخرى.

[simon]

@sda

• عندما يتم الوصول إلى المسار السابق من موقعي، أقوم بإجراء طلب GET إلى /users/by-external/userId.json
• هذا يعيد 403 Forbidden
• مباشرة بعد ذلك، يُرسل طلب POST إلى /admin/users/sync_sso
• وهذا يؤدي إلى 404 "لا يوجد مسار يطابق [POST] /admin/users/sync_sso

@sda

أشعر أن الخطأ يقع على جانب تطبيق Rails

لست متأكدًا من سبب إجرائك للطلبات إلى /users/by-external/<external_id>.json و /admin/users/sync_sso. التدفق الطبيعي هو إعادة توجيه المستخدم ببساطة إلى /session/sso_login مع تعيين حمولة SSO كمعلمات استعلام في عنوان URL. توجد تفاصيل حول الغرض من استخدام مسار sync_sso هنا: Sync DiscourseConnect user data with the sync_sso route.

يجب أن يؤدي إجراء طلب إلى /users/by-external/<external_id> باستخدام external_id غير مرتبط بعد بمستخدم في Discourse إلى إرجاع خطأ 404 (غير موجود). أما إذا كان external_id مرتبطًا بالفعل بمستخدم في Discourse، فيجب إرجاع بيانات المستخدم.

[sda]

@سيمون، الطلب الموجه إلى /users/by-external/USER-ID.json هو للتحقق مما إذا كان المستخدم يمتلك حسابًا بالفعل على نظام discourse الخاص بي. إذا تم العثور على مستخدم يحمل هذا المعرف، يتم إضافته/إزالته من مجموعات discourse المرتبطة بموقعي عبر طلب PUT إلى /admin/groups/groupId/members.json، ثم يتم إعادة توجيهه إلى my-discourse/session/sso_login.

أما إذا لم يكن لدى المستخدم حساب، يتم إنشاء الحساب عبر طلب POST إلى /admin/users/sync_sso. وبعد إنشاء المستخدم (وإضافته إلى مجموعات discourse المناسبة له)، يتم إعادة توجيهه إلى my-discourse/session/sso_login.

سأتابع الأمر وأعيد قراءة الوثائق التي أدرجتها (شكرًا لك!). لقد عمل هذا التدفق دون أي مشاكل منذ أوائل عام 2015 (وقد كان نظام discourse وخيار SSO أداة قيمة جدًا لنا!)، لذا من الغريب أن يتوقف فجأة عن العمل خلال الأسبوع الماضي.

[sda]

@سيمون، أقدر حقًا كل مساعدتك! لقد أصلحت المشكلة. لقد تم “تعطيل” Api-Username الذي كنا نستخدمه في وقت ما الأسبوع الماضي (بسبب عدم النشاط). كنتُ أفترض في البداية أن هذا قد يكون هو السبب. قمتُ بإعادة تفعيل المستخدم يوم الجمعة، وعلى الأرجح كان ذلك هو ما أصلح كل شيء في ذلك اليوم (كنتُ أعتقد في البداية أن المشكلة كانت في نقل Api-Username و Api-Key إلى رأس الطلب).

قامت منصة Discourse بتعطيل نفس المستخدم مرة أخرى صباح يوم السبت، وهو ما يفسر سبب عمل كل شيء ثم توقفه فجأة. لم أكن أتوقع أن يتم تعطيل المستخدم مرة أخرى بهذه السرعة بسبب عدم النشاط.

لقد غيّرتُ الآن Api-Username إلى “system” لمنع حدوث هذه المشكلة في المستقبل. شكرًا مرة أخرى على مساعدتك، فخلال عملية تصحيح هذا الخطأ، عادت سجلات النسخ الاحتياطي للعمل مرة أخرى، وقد تعلمتُ الكثير حقًا!