أستطيع فهم منطقك يا ستيفن، لكن هذا ليس مبالغًا فيه.
يتعامل موظفو تكنولوجيا المعلومات يوميًا مع غير المطلعين و/أو ما يُسمى بالمستخدمين غير المدربين. نحن نحاول وضع أنظمة تتكيف مع كل الاحتمالات، وهذا ليس بالأمر السهل. تُعد الهوية أمرًا بالغ الأهمية في وقتنا الحالي، ولم يتم اكتشاف هذه المشكلة إلا من خلال الاختبار. كان من الأفضل أن نُسبَق بإشعار، خاصةً وأن هذه القضية كانت موضع نقاش (وبعد إصلاحها) منذ عام 2016.
كانت أملّي أن أكون قد أغفلت شيئًا ما أو أن هناك خطأً في التكوين، لكنني أدركت الآن أن النظام يعمل كما صُمم. سنبحث عن حلول خارجية للتغلب على هذه المشكلة وسنوثّقها لمستخدمينا، ونأمل في أن يمارس آخرون ضغطًا في المستقبل لمعالجة هذه المشكلة ضمن منصة Discourse.
المستشفيات: تلك التي زرتها خلال السنوات القليلة الماضية تحتوي بالتأكيد على إجراءات قفل فريدة، لدرجة أن الممرضة المسؤولة عن فحوصات الدم يجب أن تسجل الدخول مرة أخرى بعد الابتعاد لبضع ثوانٍ فقط.
في قسم الطوارئ، قد توجد بعض الأنظمة المتخصصة التي تملك صلاحية الوصول إلى البيانات ذات الصلة بالحالات الطارئة، لكنها لا ينبغي أن تملك صلاحية الوصول إلى المعلومات الشخصية المحددة (PII) أو إلى منتدى دردشة القسم.
المكتبة:
جميع مكتباتي العامة المحلية (بما في ذلك تلك الموجودة في بعض المدن الصغيرة جدًا أو التي يعمل بها موظفون غير ملمين بالتكنولوجيا) تستخدم معرف تسجيل دخول عام. (نفس المعرف لجميع الزوار، مُعلَن على الشاشة) كما أن لديها سياسة إعادة التشغيل عند الابتعاد، ويُتوقع من الجميع، بما في ذلك الأطفال، الامتثال لها. تتضمن عملية إعادة التشغيل مسح سجل المتصفح/ذاكرة التخزين المؤقت/ملفات تعريف الارتباط تلقائيًا.
ليس أقول إن وجود سياسة أكثر حذرًا من جانب النقاش سيكون أمرًا سيئًا، بل إن بعض المواقف “المُحفزة” المذكورة في هذا الموضوع تُقلقني، لأن نسب منشورات المنتدى بشكل خاطئ هو أقل مشاكلها على الإطلاق.
2012 - مايو 2016: يتم دائمًا تعيين ملف تعريف ارتباط الجلسة في Discourse إلى دائم.
مايو 2016 - يوليو 2016: يتم تعيين ملف تعريف ارتباط الجلسة في Discourse إلى دائم افتراضيًا، ويمكن لإعداد الموقع جعله يختفي عند إغلاق المتصفح.
يوليو 2016 - اليوم: يتم تعيين ملف تعريف ارتباط الجلسة في Discourse إلى 1440 ساعة، ويتم تحديثه عند الاستخدام. يمكن لإعداد الموقع التحكم في الحد الأقصى لوقت الحياة. تم إزالة إعداد ملف تعريف ارتباط جلسة المتصفح.
تم إزالته في الغالب لأن
يمكنني فهم أن مشاركة أجهزة الكمبيوتر مع الغرباء فكرة غريبة تمامًا في بعض أنحاء العالم، بل أكثر من ذلك مع الأجهزة الشخصية المحمولة، والآن مع جائحة كوفيد-19، لكنها شائعة جدًا في بعض الأماكن مثل مكتبات المدارس وأماكن العمل، إلخ.
في معظم الأحيان، يقوم المستخدمون بإيقاف تشغيل الكمبيوتر بعد استخدامه. إيقاف تشغيل الكمبيوتر سيغلق المتصفح، لذا فإن إيقاف تشغيل الكمبيوتر سيؤدي بشكل غير مباشر إلى إنهاء الجلسة المسجلة في تطبيقات الويب.
عندما يأتي الموظف التالي للورشة التالية، يتم تشغيل الكمبيوتر مرة أخرى ولن يحتوي المتصفح على ملفات تعريف الارتباط القائمة على الجلسة بعد الآن.
صحيح، لكنني أعتقد أيضًا أن تعيين هذه القيمة إلى رقم مثل 0 يجب أن يؤدي (إذا لم يتسبب في العديد من مشكلات الدعم أو لم يكن صعبًا تقنيًا بشكل مفرط) إلى سلوك “يعمل الكوكيز فقط لمدة جلسة المتصفح”. لذا يمكن أن يشير وصف إعداد الموقع إلى ذلك.
الحد الأقصى لعمر الجلسة [الافتراضي 1440 ساعة]
سيظل المستخدم مسجّلًا الدخول لمدة n ساعة منذ آخر زيارة. عند تعيينه إلى 0، سيتم تسجيل خروج المستخدم عند إغلاق المتصفح.
المستشفيات: أنا أشارك فقط ما أعرف أنه تم من خلال الخبرة. أتفق على أن الشاشات تُقفل بسرعة، لكن ذلك لا يعني تسجيل الخروج من المتصفح، ناهيك عن تسجيل خروج المستخدم من نظام التشغيل. هل يمكنكم تخيل ما قد يفعله الناس لو اضطر الكمبيوتر لتسجيل الدخول، وتطبيق السياسات، وإعداد اتصالات الشبكة، كل ذلك قبل تحميل أي تطبيق يقوم بما يفعله الأطباء والممرضون بينما شخص ما يحتضر؟ وبالمثل، فإن تسجيلات الدخول لا تكون عادةً عبر اسم المستخدم وكلمة المرور بقدر ما تكون عبر البطاقة مع رمز PIN قصير لنفس السبب. غرف الطوارئ، وغرف العمليات، ومعظم الغرف الأخرى، لا تزال تحتاج إلى توثيق معلومات المرضى، لذا فإن العمل الذي قمت به كان متسقًا في كل مكان.
المكتبات: توجد سياسات إعادة التشغيل عند تسجيل الخروج، وهي فعالة طالما يقوم المشرفون بتنظيف ذاكرة التخزين المؤقت يدويًا لكل شيء على الجهاز، لكنني رأيت العديد من الأماكن تفعل العكس (وهو أحد الأسباب العديدة التي جعلتني لا أستخدم محطات العمل المشتركة أبدًا، مطلقًا، مع بيانات اعتماداتي). لقد رأيت نفس الإعداد غير المحظوظ في الفنادق ومقاهي الإنترنت (أو مقاهي القهوة) بانتظام، ما فائدة ذلك.
يبدو لي غريبًا أن أي تطبيق افتراضيًا يضع هذا الإعداد لجميع المستخدمين في جميع التثبيتات. الأمان ليس محور اهتمام معظم الناس عند إعدادهم لأجهزة الكمبيوتر لأول مرة، وهو معقد بدرجة كافية لدرجة أنه يصبح مهنة بدوام كامل لبعضهم. أولئك الذين يجهزون أجهزة الكمبيوتر للجمهور يجب أن يكونوا أكثر دراية، لكن المتصفحات لديها فكرة ملفات تعريف الارتباط للجلسات لتسهيل الأمر على مطوري التطبيقات لتمكين الجلسات عندما يكون ذلك بديهيًا للمستخدمين.
إجبار المستخدمين على فهم أنهم يجب أن يمحووا يدويًا ملفات تعريف الارتباط للموقع لتسجيل الخروج، بينما ستقوم العديد من المواقع بإيقاف الجلسات تلقائيًا مع مرور الوقت أو عند إغلاق المتصفح، يبدو وكأنه يطلب الكثير من الناس. عدم السماح بالبدائل تمامًا بحيث يجب على المستخدم أن يتذكر استخدام رابط تسجيل الخروج المحدد في Discourse يصبح مشكلة عندما يغفل المستخدم عن الرابط لأي سبب؛ من الذاكرة:
يتصفح المستخدم بعيدًا عن Discourse عبر رابط.
يتصفح المستخدم بعيدًا عن Discourse لأنه يستخدم اللسان للذهاب إلى مكان آخر عمدًا.
يغلق المستخدم اللسان على عجل ليذهب إلى فصل دراسي/اجتماع/إلخ.
ينهار المتصفح لأي سبب.
منفذ SSO لديه SAML لتسجيل الدخول، لكنه لا يعرف أن التطبيق يتطلب تسجيل خروج صريح لإنهاء جلسة التطبيق.
أيضًا، شهران (2) يبدو وقتًا طويلاً جدًا لاستمرار تسجيل الدخول. أعرف أن بعض المواقع الأخرى قد تفعل ذلك حاليًا، أو حتى لفترة أطول، لكن المستخدمين يمكنهم عادةً التحكم في ذلك عبر مربعات الاختيار “كمبيوتر عام”، وهو ما لا ينطبق مع SSO، أو ربما لا ينطبق على الإطلاق (أنا لست خبيرًا في Discourse).
يبدو لي أن هذا خيار إداري في الأساس. إنه ميزة أمنية. على المدى الطويل، قد ننظر في إنشاء قائمة مسموح بها لعناوين IP تتجاوز هذا القيد (لذلك على سبيل المثال، تظل أجهزة الكمبيوتر داخل الشبكة المؤسسية مسجلة الدخول، بينما يتم تسجيل خروج أجهزة الكمبيوتر خارجها تلقائيًا).
أعتقد أنه، بطبيعة هذا الطلب، فإن الميزة مخصصة لكل مستخدم على حدة.
فبعض المستخدمين يستخدمون حواسيبهم في منازلهم أو مكاتبهم، ولا يحتاجون إلى انتهاء صلاحية ملفات تعريف الارتباط (الكوكيز)، وبالتالي يجب أن يكون ذلك خيارًا لهم.
بينما قد يكون مستخدمون آخرون من هؤلاء “المسافرين” الذين يستخدمون حواسيبًا مشتركة في المقاهي، ويرغبون في انتهاء صلاحية جلساتهم.
وبما أن طبيعة هذه الميزة تتعلق بأمان حساب المستخدم، فقد تم تنفيذ هذا الإعداد عادةً كإعداد للمستخدم أو مربع اختيار يظهر له عند تسجيل الدخول.
فعلى سبيل المثال، كان نظام vBulletin يحتوي على هذه الميزة جاهزة للاستخدام (OOTB) منذ أكثر من عقد، وعند تسجيل الدخول كنا نحدد ببساطة مربع الاختيار إذا كان “المستخدم” يريد استمرار جلسته.
إن “الأمان” مخصص لحسابات المستخدمين، لذا فقد كان هذا الإعداد عادةً مخصصًا لكل مستخدم على حدة في الماضي، علماً بذلك.
تحديث: عندما يكون لدى المستخدم حساب مميز (مثل المشرف أو المراقب أو القائد، إلخ)، فإن هناك أيضًا قضية أوسع تتعلق بأمان الموقع بشكل عام.
لقد رأيت هذا التنفيذ في العديد من المواقع، والتنفيذ النموذجي هو:
ابق مسجّل الدخول لمدة 30 يومًا
[ تسجيل الدخول ]
غير متأكد متى سنصل إلى هذا، ولكن عندما نفعل ذلك، سنحتاج على الأرجح إلى إعداد موقع لتمكين هذا الخيار. هناك تعقيدات حول مكان عرض مربع اختيار مثل هذا إذا كانت تسجيلات الدخول عبر الشبكات الاجتماعية مفعّلة.
نعم، لم تكن تسجيلات الدخول عبر وسائل التواصل الاجتماعي “من تخصصنا” أبدًا بسبب تتبع السلوك؛ لذا فإن منظور ضيق جدًا مقارنة بمتطلبكم الأوسع والأكثر تعقيدًا لدعم وسائل التواصل الاجتماعي.
شكرًا لكم على كل العمل الجيد الذي تقوم به فرقكم. أحسنتُم.
أولاً وقبل كل شيء: شكرًا جزيلاً على الإصلاح السريع. لدي سؤال واحد فقط: هل من الممكن تحويل هذا إلى إعداد خاص بكل مستخدم مع قيمة افتراضية محددة، بحيث يتمكن المستخدمون من إلغاء الاشتراك من خلال تفضيلاتهم؟