تعمل مصادقة SSO الخاصة بـ Discourse مع WordPress فقط عبر عنوان URL /core/wp-admin

لقد قمت بنشر إضافة ووردبريس جديدة تعتمد على نظام الدخول الموحد (SSO) الخاص بـ Discourse، لكنني واجهت خطأً غريبًا يؤثر فقط على النشر المباشر للموقع.

على البيئة المحلية، يمكنني تسجيل الدخول واستخدام معلمة redirect_url للعودة إلى الصفحة المطلوبة. أما على الموقع المباشر، فإن نظام SSO يعمل فقط إذا كانت قيمة redirect_url هي رابط wp-admin، على سبيل المثال:

يعمل نظام SSO بشكل ممتاز…
https://www.example.com/core/wp-login.php?redirect_to=https%3A%2F%2Fwww.example.com%2Fcore%2Fwp-admin%2F&reauth=1

لا ينجح نظام SSO في المصادقة، بل يعيد فقط إلى صفحة تسجيل الدخول/النشر
https://www.example.com/core/wp-login.php

هل واجهت هذا من قبل؟ هل لديك أي أفكار حول أين يمكن البحث؟ إذا استمر المشكلة، سأضطر إلى بناء آلية إعادة توجيه خاصة بي لالتقاط روابط wp-admin.

أنا واثق جدًا من أن هناك إما خادم وكيل عكسي مُعد بشكل خاطئ أو شيء مشابه يحدث هنا. هل تستخدم Cloudflare بالصدفة؟

نعم، إنها Cloudflare. هل توجد أي إعدادات في Cloudflare يمكننا تجربتها؟

إيقاف السحابة البرتقالية.

ها ها، هذا ليس قرارًا مني، فالموقع يستخدم Cloudflare كذاكرة تخزين مؤقت رئيسية. سأحتاج إلى إجراء بعض الأبحاث حول خوادم الوكيل العكسية لأرى ما إذا كان بإمكاني تعديل أي من الإعدادات في CF

هناك عشرات المواضيع حول المشاكل الناجمة عن تحسينات Cloudflare. يمكنك استخدام Cloudflare كـ CDN، مما سيجعل Discourse يعيد توجيه المحتوى الذي يمكن تخزينه مؤقتًا عبر Cloudflare فقط.

يمكنك أيضًا تعطيله مؤقتًا لمعرفة ما إذا كان ذلك يحل المشكلة.

ببساطة قم بتعطيل “الأداء” و “Rocket Loader” من Cloudflare على Discourse عبر قواعد الصفحات، وهو ما سيصلح المشكلة على الأرجح.

نعم، هذا مزيج غريب من المشكلات، ويبدو أن جزءًا منه يعود إلى دليل تثبيت ووردبريس أيضًا. لقد كتبت حلاً مؤقتًا مؤقتًا يقوم دائمًا بإعادة التوجيه إلى /core/wp-admin، ثم هناك معامل استعلام نهائي هو ?final_redirect_url يلتقطه خطاف خاص بي وينفذ الإجراءات اللازمة لإعادةنا إلى المكان الذي نريد الوصول إليه.

يبدو أنك تستخدم WP Discourse – WordPress plugin | WordPress.org مع تفعيل خيار عميل SSO (حيث يعمل Discourse كمزود SSO). هل يمكنك تأكيد صحة ذلك؟