Drupal SSO يولد جلسات مستخدم غير صحيحة

مرحباً،
نحن نستخدم الدخول الموحد (SSO) من Drupal، والسلوك غير المقصود هنا هو أن جميع المستخدمين يرون خادم Drupal الخاص بنا مسجلاً الدخول بالإضافة إلى جلستهم الحالية. وهذا يسبب الكثير من القلق والارتباك في مجتمعنا حيث يرون جهازًا آخر مسجلاً الدخول وهو ليس جهازهم.

هل يمكن تعطيل هذه الميزة، أو الأفضل من ذلك، هل يمكننا استثناء عناوين IP معينة لإخفاء خادمنا من قائمة الأجهزة المستخدمة حديثًا؟

لا يؤدي استخدام موفر SSO خارجي إلى ظهوره في هذه القائمة.

ما تراه قد يكون أثرًا ناتجًا عن شيء آخر، مثل إنشاء مفاتيح API للمستخدمين، وما إلى ذلك.

لقد صادفت هذه المشكلة من قبل عندما كان موقع Drupal مزوّدًا لـ SSO لـ Discourse. لم أرَ مشاكل مماثلة مع مزوّدي SSO الآخرين. هل هناك وحدة Drupal تستخدمها لـ SSO؟ إذا كان الأمر كذلك، هل يمكنك إخبارنا أين يمكن العثور عليها؟

يمكنك إخفاء قسم “الأجهزة المستخدمة مؤخرًا” باستخدام CSS. قد يكون هذا حلاً مؤقتًا جيدًا للمشكلة.

.control-group.pref-auth-tokens {
    display: none;
}

نحن نستخدم وحدة المساهمة “Discourse Forum Integration” على الرابط التالي: https://www.drupal.org/project/discourse

شكرًا على التلميح؛ لقد قمنا مؤقتًا بإخفاء هذا باستخدام CSS. ولكن سيكون من الجيد معرفة ما إذا كان من الممكن تكوينه لإخفاء خادمنا فقط من القائمة للسماح للمستخدمين بمواصلة رؤية أجهزتهم المستخدمة مؤخرًا.

أقترح التواصل مع مطور Drupal - يبدو أن آخر تحديث للوحدة كان في عام 2015، مع دعم إصدار Discourse المذكور 1.2.0.beta5 (الذي أطلقناه في يناير 2015). بينما يسعدني رؤية أنه لا يزال يعمل، فمن غير المفاجئ وجود بعض المشكلات الطفيفة.

من الجدير بالذكر أيضًا أن وحدة Drupal المرتبطة أعلاه متاحة فقط لـ Drupal 7، والتي ستصل إلى نهاية دعمها في نوفمبر 2021. (ليست غدًا، لكنها قريبة بما يكفي.)

نعم، شكرًا لك، نحن على علم بذلك (وليسوا سعداء لأن موقعنا تم إطلاقه مؤخرًا :disappointed_relieved:)

لقد ألقيت نظرة سريعة على وحدة Drupal Discourse. ليس من الواضح لي ما الذي يسبب المشكلة، ولكن لسبب ما، يتم تعيين قيمة وكيل المستخدم (User Agent) وعنوان IP الخاص بالعميل إلى قيم خادم Drupal بدلاً من عنوان IP ووكيل المستخدم الخاص بالمستخدم أثناء تسجيل الدخول عبر SSO. قد يكون هذا مرتبطًا بكيفية عمل دالة drupal_goto.

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

تم تحديث هذه الوحدة آخر مرة في عام 2015. توجد وحدة أخرى لـ Drupal Discourse SSO تم تحديثها مؤخرًا: https://www.drupal.org/project/discourse_sso. أعتقد أنها توفر فقط وظائف SSO. ولا يبدو أنها تحتوي على أي كود يضيف محتوى Discourse إلى موقع Drupal.

شكرًا لك على المعلومات الإضافية، سيمون. نحن بالفعل نفعل ذلك بالضبط؛ حيث يستخدم قسم تعليقات المدونة موضوعًا في Discourse لمناقشة المستخدمين، ثم يتم عرض محتوى هذا الموضوع أيضًا في مقال المدونة في Drupal.

هل هذا هو المكان المناسب لمعرفة المزيد عن إبطال مصادقة واجهة برمجة التطبيقات (API)؟ Discourse REST API Documentation

شكرًا مرة أخرى!

نعم، يحتوي طلب POST النموذجي المذكور في بداية هذا الموضوع على المعلومات التي تحتاجها. لإصلاح وحدة Drupal Discourse لتستخدم المصادقة القائمة على الرؤوس، يلزم إجراء تغيير بسيط فقط في كودها.

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