مرحبًا، لقد تلقّيت معلومات تفيد بأن بعض أعضاء منتداي يتم تسجيل خروجهم تلقائيًا بعد 20-30 دقيقة.
أستخدم نظام تسجيل الدخول الموحد (SSO)، لذا أتساءل عما إذا كانت المشكلة مرتبطة بسيناريو يتضمّن تسجيل الأعضاء دخولهم إلى الموقع الرئيسي، ثم الانتقال إلى Discourse (حيث يبدأ ذلك جلسة جديدة هناك؟)، ثم العودة إلى الموقع الرئيسي (مما يعني أن Discourse أصبح خاملًا)، ثم العودة إلى Discourse مرة أخرى ليتم تسجيل خروجهم بطريقة ما.
(مع ذلك، لا يبدو هذا منطقيًا تمامًا، لأنه في كل مرة يدخل فيها الأعضاء إلى Discourse، يجب أن يتم إعادة تعيين “مهلة الخمول” إلى 0، أليس كذلك؟)
وجدت بعض المواضيع المتعلقة بالمهلة الزمنية وما شابه ذلك هنا في قسم Meta، لكن لا يبدو أن أيًا منها يقدم إجابة واضحة.
السؤال: هل توجد إعدادات تمنع تسجيل خروج الأعضاء حتى يظلوا خاملين لفترة زمنية محددة (X)؟ لا أتمكن من العثور عليها.
أرى في إعدادات Discourse الخاصة بي أن “أقصى عمر للجلسة” مضبوطة على ساعة واحدة، لكنني لا أعتقد أن هذا يحدث فرقًا فعليًا عند استخدام تطبيق SSO، أليس كذلك؟ (لاحظ أنه عند تسجيل عضو الخروج من موقعي الرئيسي، أرسل رسالة /logout إلى Discourse فقط للحفاظ على النظام. وعندما يقوم العضو بأي نشاط في Discourse، أقوم بتحديث وقت آخر نشاط في موقعي الرئيسي، لذا لا يمكن أن يكون الموقع الرئيسي هو من يستنفد المهلة الزمنية. أنا أضيف الآن أكواد تصحيح إضافية للتأكد من أن كل شيء يعمل كما يجب.)
ينطبق ذلك على نظام تسجيل الدخول الموحد (SSO)، لذا فمن المرجح أن يكون هذا هو مصدر مشكلتك. بعد ساعة واحدة من عدم النشاط، سيتم إنهاء جلسة Discourse وسيضطر المستخدمون إلى إعادة المصادقة عبر نظام تسجيل الدخول الموحد (SSO).
هذا مقبول تماماً… فبعد ساعة من عدم النشاط، يجب أن يتم تسجيل خروجهم.
المشكلة هي أنني أتلقى تقارير عن أشخاص يتم تسجيل خروجهم بعد 20-30 دقيقة.
هل توجد إعدادات لوقت انتهاء الجلسة الخاملة هذا البالغ ساعة واحدة؟ كما ذكرت في منشوري الأصلي، لا أستطيع العثور عليه… ويبدو أن هذا هو المكان الأول الذي يجب التحقق منه، أليس كذلك؟
فقط لاستبعاد السبب الأكثر وضوحًا… هل من الممكن أن يكون الناس مخطئين بشأن الوقت الدقيق؟ 30 دقيقة وساعة ليستا مختلفتين كثيرًا
للمتابعة في استكشاف هذه المشكلة، أقترح أن تكون الخطوة التالية هي النظر في البيانات المتاحة في جداول user_auth_tokens و user_auth_token_logs. فهي تحتوي على جميع المعلومات المتعلقة برموز الجلسة وانتهاء صلاحيتها.
حسنًا. عندما يستخدم الأشخاص المنتديات ويقرأون المواضيع وما إلى ذلك، إذا قاموا بأي إجراء يولد حدثًا (مثل إنشاء منشور، أو إنشاء موضوع، أو تعديل منشور، وما شابه)، فإنني أتلقى رسالة عبر الويب هوك. تخبر هذه الرسالة الموقع الرئيسي بأن المستخدم لا يزال نشطًا، مما يسمح لي بتحديث قيمة “آخر نقرة” في جلسته، وبالتالي منع تسجيل الخروج. وهذا ما يجب أن يحدث، وكل شيء على ما يرام.
ومع ذلك، إذا كان العضو يقرأ الرسائل فقط لفترة من الوقت… فإن وقت خمول المستخدم في ديسكورش يتم إعادة تعيينه في كل مرة يقوم فيها بأي إجراء (وهو أمر جيد)، لكن موقعي الرئيسي لا يتلقى أي رسائل ويب هوك تشير إلى أن المستخدم نشط، لذا بعد ساعة واحدة من عدم وجود أي نشاط (يبدو وكأنه ذهب إلى المنتديات وترك الحاسوب)، يفترض الموقع الرئيسي أنه انتهى الأمر به ويقوم بتسجيل خروجه.
يبدو أن هناك ثغرة في المنطق هنا. لتنفيذ SSO بشكل صحيح، ألا ينبغي أن تكون هناك طريقة لـ ديسكورش لإخباري إذا كانت جلسة المستخدم نشطة (حتى لو كان يقرأ فقط)؟ ربما يجب على ديسكورش إرسال نبض كل 5 دقائق إذا كان العضو نشطًا لكنه لم يولد أي رسائل ويب هوك أخرى.
أو ربما عندما يعتقد موقعي أن المستخدم قد انتهى وقت جلسته، يجب علي الاتصال بـ ديسكورش والسؤال عما إذا كان المستخدم نشطًا هناك. هل هناك طريقة للقيام بذلك؟ (أرى الرابط Is there an endpoint to check if a user is logged in - #3 by pfaffman لكنني لا أستطيع تحديد ما إذا كان هذا ما أريده تمامًا، و /session/current.json غير موجود في وثائق الـ API.) ومع ذلك، سيؤدي ذلك إلى عدد هائل من مكالمات الـ API — فأنا أقوم بتسجيل خروج حوالي 15-20 مستخدمًا كل دقيقة في موقعي بسبب عدم النشاط، لذا سيتطلب ذلك مكالمة لكل واحد منهم (وربما أكثر من مكالمة واحدة إذا لم يكن لدي ذاكرة تخزين محلية لـ معرف ديسكورش الخاص بهم).
لست متأكدًا مما تقصده بإبقاء النظامين مستقلين؟ أخبرني إذا كنت أغفل طريقة واضحة لحل المشكلة التي عرضتها، من فضلك!
وإلا، يبدو أن خياراتي هي:
عندما ينتهي وقت المستخدم على الموقع الرئيسي، وقبل تسجيل خروجه، اتصل بـ Discourse وتحقق من قيمة last_seen لمعرفة ما إذا كان العضو نشطًا فعليًا في المنتديات (ولكنه لم يقم بأي إجراء يولد استدعاءً لـ webhook). المزايا: سهل التنفيذ. العيوب: سيولد عددًا كبيرًا من مكالمات API، وهو ما أواجه صعوبة في التعامل معه بالفعل بسبب حدود المعدل.
إنشاء إضافة خاصة بي للتحقق من موقعي الرئيسي بين الحين والآخر، حتى أتمكن من تحديث وقت آخر نشاط للمستخدم على موقعي الرئيسي. المزايا: يبدو وكأنه الحل “الصحيح” (لإظهار النشاط برسالة دفع)؛ أنيق إلى حد ما. العيوب: ليس سهل التنفيذ.
تغيير وقت تسجيل الخروج على موقعي الرئيسي إلى ساعتين. المزايا: سهل التنفيذ. العيوب: هل هناك أي عيوب؟
لا تقلق بشأن الأمر. يتم تسجيل خروج المستخدمين في منتصف جلسة Discourse ويشكون بشدة. هذا ما أعمل به حاليًا. المزايا: سهل التنفيذ، haha. العيوب: تجربة مستخدم رديئة للغاية.
هل أغفلت شيئًا؟
يبدو أن الخيار رقم 3 سيكون إجابة جيدة، رغم أنني بحاجة إلى التفكير في آثار وجود وقت تسجيل خروج أطول على الموقع الرئيسي.
لا يزال الخيار رقم 1 يبدو لي هو الأفضل، لكن عليّ حينها أن أجد حلاً لكيفية منع كل هذه المشاكل المزعجة المتعلقة بحدود المعدل. أتمنى لو كان هناك طريقة لإيقاف جميع حدود المعدل في Discourse (وفي nginx أيضًا، نظرًا لأنني أستخدم تثبيت Discourse عبر Docker) بشكل نهائي ودائم. لا أحتاج إلى أي منها. إنه فقط موقعي الرئيسي يتواصل مع نسخة Discourse الخاصة بي. لا أسمح بمفاتيح API للمستخدمين، وأنا الوحيد الذي يمتلك مفتاح API للنظام. إنه نظام مغلق تمامًا، وحدود المعدل لا تفعل سوى (مستمرة) عرقلة عملي. أعتقد أن هذا موضوع مختلف.
إذا كنت بحاجة إلى الحفاظ على السلوك الذي أوضحتَه، نعم، أعتقد أن هذه هي الخيارات الأربعة. لكن إذا قمت بتغيير السلوك قليلاً، فسيعمل بشكل أفضل مع الأدوات المتاحة.
الجزء غير المألوف في إعدادك هو:
أنت تنهي جلسة Discourse في كل مرة تنتهي فيها صلاحية الجلسة على موقعك الرئيسي. إذا قمت بإزالة هذا الجزء، أعتقد أن الإعداد سيتطابق مع الإعدادات النموذجية.
ما زلت بإمكانك استدعاء /logout عندما يسجل المستخدم الخروج بشكل صريح من موقعك الرئيسي. فقط لا تستدعه عندما تنتهي صلاحية الجلسة بشكل طبيعي.
لا يمكنني التحديد من المنشور الأصلي، لكن هل تشغلون موقعًا متخصصًا للغاية يركز على مشاركة معلومات حساسة للغاية، أو حيث يسجل معظم المستخدمون الدخول من أجهزة كمبيوتر عامة مشتركة أو شيء مشابه؟
بكل المقاييس، يبدو أن الحل الأبسط هنا هو عدم الإفراط في عدوانية انتهاء جلسات المستخدمين وإجبارهم على تسجيل الخروج. تفضيلي كمشترك هو دائمًا: “لا تسجل خروجي أبدًا إلا إذا نقرت تحديدًا على زر تسجيل الخروج”. وإذا لم يكن ذلك ممكنًا، فهل يمكنكم على الأقل جعل المدة يومًا واحدًا أو أسبوعًا واحدًا أو ما شابه؟
أرى… هذا حل جيد؛ أعتقد أن عددًا كافيًا من أعضائي يستخدمون خانة “ابقِ مسجّلًا الدخول” في صفحة تسجيل الدخول، مما سيجعل إعادتهم إلى الموقع الرئيسي سلسة. إذا كانت جلستهم قد انتهت صلاحيتها على الموقع الرئيسي، فسيتم تسجيل دخولهم (بشكل غير مرئي) في تلك اللحظة بالذات. Hmm.
إنه موقع مخصص لقطاع من السكان يهتمون بالخصوصية بشكل كبير. لكنني أفهم ما تقصده وأعتقد أنني يمكنني ببساطة اتباع ما اقترحته أنت (وديفيد).
شكرًا لكما كثيرًا. لم يكن لدي فهم واضح لـ “الصورة الأكبر” هنا، أو كيفية تعامل المواقع الأخرى مع هذا النوع من السيناريوهات… والآن لدي وأرى بعض الحلول الممكنة لحالتي. تقديري كبير لكم!
وأرى بعض الحلول الممكنة لحالتي. تقديري كبير لكم!