أنا أعمل على موقع ووردبريس متصل بمنتدى Discourse بحوالي 200 ألف مستخدم.
باستخدام إضافات OAuth Single Sign On - SSO (OAuth client) و WP-Discourse، نقوم بربط المنشورات من WP بـ Discourse ونجعل المستخدمين يسجلون الدخول على WP باستخدام مثيل مستخدم WP الخاص بهم، والذي يقوم بعد ذلك بتسجيل دخولهم إلى Discourse أيضًا.
الآن، ظهرت مشكلة، كلما قمنا بتعيين إعدادات Discourse على عدم طلب تسجيل الدخول.
هذه هي خطواتنا:
يسجل المستخدم الدخول إلى ووردبريس
ينقر المستخدم على رابط يؤدي إلى Discourse (موضوع، أي رابط يؤدي إلى Discourse)
==> يرى المستخدم الآن Discourse كما لو لم يكن مسجلاً الدخول! لكنهم مسجلون الدخول، في اللحظة التي سجلوا فيها الدخول إلى ووردبريس!
الآن ينقر المستخدم على تسجيل الدخول إلى Discourse أو على أي رابط موضوع
يتم تحديث الصفحة ويكون المستخدم مصادقًا عليه الآن!
قيل لنا أن هذا متوقع، وأننا بحاجة إلى القيام بما يلي:
عندما يكون المستخدم مسجلاً الدخول، يجب أن تكون جميع الروابط التي تؤدي إلى Discourse من ووردبريس كما يلي: https://our-discourse-instance.com/session/sso?return_path={ORIGINAL URL OF DISCOURSE WE POINT TO, like a topic url, or so}
عندما يكون المستخدم مسجلاً الخروج، يمكننا الربط بـ {ORIGINAL URL OF DISCOURSE WE POINT TO, like a topic url, or so} مباشرة، مثل: https://our-discourse-instance.com/t/topic-slug
أنا أشك بشدة في أن هذا هو النهج الخاطئ لحل هذه المشكلة، لأن:
ماذا لو قام مستخدم، أثناء تسجيل الدخول إلى Discourse، بنسخ رابط موضوع، وشاركه مع شخص مسجل الدخول أيضًا إلى WP/DIscourse؟ سيحصلون على نفس الخطأ كما هو موضح أعلاه في #2، حيث لن يتم إلحاق لاحقة URL كهذه.
لماذا يحتاج المستخدم المسجل الدخول إلى إعادة التوجيه إلى session/sso?return_path=؟ ما هو السبب المنطقي والتقني وراء ذلك؟
لماذا يتم حل المشكلة بمجرد قيام المستخدم بتحديث الصفحة (تحميل رابط موضوع، الضغط على تسجيل الدخول، إلخ)؟
لماذا لا يتم توثيق هذا على نطاق واسع، إذا كان هذا هو النهج المتوقع بالفعل؟
لماذا لا يتم ذكر ذلك في واجهة برمجة التطبيقات (API)، حيث يمكننا سحب أي رابط موضوع من Discourse، ولا يوجد في أي مكان مكتوب أن المستخدمين المسجلين لن يتمكنوا من الوصول إلى المحتوى على الفور ويحتاجون أولاً إلى القيام بتحديثات غريبة، أو أننا بحاجة إلى إلحاق معلمات URL غريبة لا تقوم في الواقع بتحويل أي شيء؟
سأقدر حقًا رأيًا موثوقًا به حول هذا الأمر، لأنني لست مقتنعًا على الإطلاق بأن هذا هو السلوك المتوقع!
إذا كان كذلك، أود الاستفسار:
لماذا هذا ضروري بالفعل و
ما هو المخطط للقيام به بخصوصه (لأن هذا بالتأكيد ليس مثاليًا، انظر النقطة 1 من أسباب عدم توقع ذلك)
إذا كنت تريد إعادة توجيه المستخدمين تلقائيًا إلى تسجيل الدخول عند انتقالهم إلى أي مسار في منتداك، فستحتاج إلى تمكين إعداد login required. هذا هو السلوك المتوقع بالفعل.
بينما لا يزال الأمر غريباً، لقد مضيت قدماً وأضفت إعادة توجيه إلى session/sso?return_path= عند تسجيل دخول المستخدم في wp
تم تعيين مسار العودة إلى المُحيل من wp (إن وجد) أو الصفحة الرئيسية لـ wp
هذا يعمل بشكل رائع ويضمن تسجيل دخول المستخدم في كلا المثيلين
كان عليّ تمكين الإعداد في discourse للسماح بـ “أي مسار عودة”، حيث أن discourse يمنع مسارات العودة “الخارجية” افتراضياً
هل ترى أي مشكلة في تمكين هذا الإعداد؟
شكراً مرة أخرى على الرد اللطيف والتأكيد “الرسمي” بالإضافة إلى رابط التوثيق!
عادةً ما أنصح العملاء بعدم إجراء إعادة توجيه تلقائي كهذا. أتفهم سبب شعورك بأن هذه مشكلة، إنه شعور شائع وليس نادرًا، ومع ذلك، فإن النهج القياسي يعمل بشكل جيد للعديد من المواقع الكبيرة، أو الأكبر، من موقعك وقد لا يعمل إعادة التوجيه التلقائي في بعض السيناريوهات، مما يؤدي إلى تجربة مستخدم سيئة.
تسجيل الدخول مرة واحدة وتسجيل الدخول تلقائيًا في كل مكان الذي تتوقعه هو كيف تعمل الخدمات المترابطة مثل ميتا (على سبيل المثال، تسجيل الدخول إلى فيسبوك وتسجيل الدخول إلى انستغرام) أحيانًا لأنها منصات خاضعة للرقابة المركزية (على الرغم من أن الخدمات المركزية أحيانًا تعمل بنفس الطريقة التي تعمل بها DiscourseConnect أيضًا).
على النقيض من ذلك، أنت تتعامل مع أطر برمجية مفتوحة المصدر مستقلة هنا (أي ووردبريس و Discourse). يمكن إعدادها للعمل بفعالية بالطريقة التي تتوقعها، ولكنها تتطلب عملًا مخصصًا يأخذ في الاعتبار حالة الاستخدام الخاصة بك. لن تعمل أبدًا مثل نظام المصادقة مثل DiscourseConnect الذي يخدم آلاف حالات الاستخدام المختلفة.
لا، مع التحذير بأنني سأشكك في فرضية الحاجة إليه. ولكن بدون مزيد من المعلومات، لا يمكنني رؤية مشكلة في استخدامه.
هل يمكن أن يكون هذا خطر إعادة توجيه غير صالح، كما هو موضح هنا؟
يمكنني أن أرى كيف أن “السماح بأي قيمة إرجاع” يسمح بالفعل بإعادة التوجيه إلى أي مكان
ولكنني لست متأكدًا مما إذا كان هذا سيكون حقًا خطرًا، نظرًا لعدم مشاركة أي بيانات حساسة في عنوان URL لإعادة التوجيه أو إليه.
منتدى Discourse يقوم بتفعيل الإعداد في Discourse للسماح بـ “أي مسار عودة”.
هذا يعني أنه يمكنك الآن زيارة your-discourse.tld/session/sso?return_path=ANYTHING
يمكن أن يكون ANYTHING عنوان URL خارجيًا.
وبالتالي، فإن هذا يفتح ثغرة أمنية من حيث أنه يمكن على الأقل تنظيم محاولة تصيد احتيالي:
موقع ويب خبيث ينشئ زرًا يقول “انتقل إلى المجتمع المذهل!”
رابط الزر هو your-discourse.tld/session/sso?return_path=BACK TO MALICIOUS SITE
يضغط المستخدم على الزر، ويسجل الدخول في المجتمع، مما يعيده إلى الموقع الخبيث.
هناك، قام الجهة الفاعلة الخبيثة بتنفيذ صفحة تبدو تمامًا مثل المجتمع وتقول “حدث خطأ ما أثناء تسجيل الدخول، يرجى المحاولة مرة أخرى”.
يقدم المستخدم نموذج تسجيل دخول يبدو جيدًا ويتطابق مع مظهر المجتمع.
هل حصل الجهة الفاعلة الخبيثة الآن على بيانات تسجيل الدخول؟
وبالتالي، ربما لا ينبغي استخدام الإعداد “أي مسار عودة” أبدًا لموقع يحتوي على مستخدمين يسجلون الدخول، إلا إذا كان كل مستخدم يعرف بالضبط ما الذي يبحث عنه.
هل ترى هذا الخطر أيضًا؟
لماذا لا يستطيع مطورو Discourse الذين يصنعون الإضافات/الكود الذي يمكنه التفاعل مع هذا الإعداد تقديم إشارة إلى “نعم لا مشكلة” أو “لا على الإطلاق”؟
ليس هناك الكثير من الأشياء التي يمكن تغييرها في معلمة عنوان URL هذه. إما أنها موجودة أو لا، إما أنها تسمح بالخارجيات أو لا.
ربما أتعمق في منطقة لا ينبغي لي، مثل “لا تناقش المشكلات الأمنية هنا”؟ سأفهم ذلك بالطبع، فالعديد من المنصات لا تسمح بالتحدث علنًا عن المشكلات الأمنية المحتملة التي لم يتم تعريفها بوضوح عند تمكينها
لأن قيمة الإعدادات تعتمد على كيفية استخدامها، وهذا هو السبب في أنها إعدادات وليست مجرد “ميزات”. لو كان هناك إجابة بسيطة لسؤالك لما كان هناك إعداد في المقام الأول.
أقدر أن هذه الاستجابة القانونية إلى حد ما محبطة. لكنك بحاجة إلى نصيحة خاصة بحالة استخدامك، وهو أمر لست في وضع يسمح لي بتقديمه لك هنا.
