My problem is when using SSO, so I really need to be a site setting.
When we detect that the SSO is down we nuke the cookies, but if the user left the pc with a valid SSO session, and other user opens it, he can be logged as someone else.
Setting expires to session may solve this.
Guys, I traced down making the _t cookie having a smaller expires.
The problem is that Discourse doesn’t seen to handle this very well atm.
We get a /login redirect but the it results in a ajax error instead of rendering the /login page properly.
Should I add special code to handle this expiration on the $.ajax function?
Probably best to consult with @sam first before proceeding, but in general, I would like it if people could set their site’s cookies to expire, say, weekly if they want that to happen.
The _t cookie is the wrong spot imo, we should start off by adding a column to user table that specifies when the auth token was created
Then it is trivial to expire cause a site setting can check for stale tokens when doing current user resolution
I do not like the idea of having this logic up to clients, cause clients can cheat
Since a timed cookie is a very bad idea, I have done a switch between Session and Permanent. Permanent still default, so no changes for most people.
My use case is enterprise communities, where sharing computers happen very often. People are used to services not persisting trough a browser restart or a computer restart and are posting on each other account 
.
Keep in mind we have 100k+ non tech employees 
Sure @sam will need to review.
The feature provided by @Falco got removed by commit a9207dafa
It would be great to bring back this feature. Because some users don’t perform an explicit logout by hitting the button. They’ll just close the browser assuming this would terminate their session as well. But the session will be still alive.
Please let the admin decide whether or not to use permanent sessions. It is a valuable feature for specific communities and use cases.
Now that my auth changes are all done a ton of stuff is easily on the table.
Personally I think the best change we can make here is:
We already have “maximum session age” which is set to 1440 hours, by heavily reducing it we can “sort of” approximate a session based cookie, except that unlike a session based cookie, closing and opening tabs will keep you logged on.
These 3 site settings and bits of UI needed for “stay signed in” option are probably doable in 1-2 days of work.
@codinghorror your call if
We only need the 1440 value as a site setting the other stuff can be ignored.
Does anyone know if this was ever implemented? I would like the ability to control when a user’s session times out if possible.
I can’t recall if we added the session duration site setting, do you remember @sam?
Yep, it’s there in admin:
The default is quite generous – around two months. I’m not sure if it supports fractional values, though – I can see that some people would prefer very short sessions (five to fifteen minutes), but the setting itself is in hours.
Yeah we have “maximum session age”: User will remain logged in for n hours since last visit
Set to 1440 by default
لم أستطع العثور على أي شيء أحدث من هذا. يمكن تعيين الحد الأقصى لعمر الجلسة إلى ساعة واحدة كحد أدنى.
هذا غير مفيد عندما يُستخدم الكمبيوتر في بيئة مشتركة.
هل ظهرت أي حلول حديثة لهذه المشكلة؟ في جوهر الأمر، أحتاج إلى نسيان المستخدم عند إغلاق المتصفح، مع تسجيل الدخول عبر SSO.
شكرًا لك
هذا بالضبط ما كان يقوم به تصحيحي، لكنه تم إلغاؤه 
يمكنك التحقق من الكود وتطبيقه على إضافة (plugin).
سؤال لا علاقة له بمنصة Discourse على الإطلاق:
كيف يحدث هذا أصلاً؟ يُفترض أن:
حسناً، هذا يمثل تهديداً أمنياً - سأبدأ موضوعاً جديداً
لوك، العالم بأسره لا يعيش في بيئات مكتبية خاضعة لرقابة صارمة.
خذ على سبيل المثال المواقع ذات الوصول المفتوح داخل المؤسسات الأكاديمية، والأجهزة الموجودة في المكتبات وما شابه ذلك. فكثيرون لا يعتبرون توفير واجهة متصفح خطرًا أمنيًا.
أتفق تمامًا على أن الأشخاص يمكنهم تهيئة أجهزتهم وبرامجهم لتجنب هذه المشكلة، لكن ليس الجميع يقوم بهذا الإعداد. لذا، فإن توفير منتدى لمستخدمينا نعلم فيه وجود ثغرات أمنية إذا لم تكن الأجهزة والبرامج التي تعمل عليها مهيأة بطريقة معينة يجعلنا مسؤولين، كما أرى.
هذا سؤال منطقي. البيئات التي تستخدم عادةً تجربة سطح مكتب مشتركة تشمل المكتبات والمدارس والمستشفيات، رغم وجود غيرها. كما يمكنك تخيل ذلك، تشمل العوامل المحركة التركيز على سهولة الاستخدام (فطلب تذكر اسم المستخدم من أطفال الصف الأول أمر صعب بحد ذاته، لكن إضافة كلمة مرور لا تتضمن اسم المستخدم أو الاسم الشخصي، وتتضمن أرقامًا ورموزًا خاصة؟ ها!), وعدم وجود مستخدمين فريدين (المكتبات غالبًا تفتقر إلى أسماء المستخدمين لأن ذلك قد يُعدّ شكلاً من أشكال تتبع المستخدمين، وهو ما يزعج الكثيرين في بيئات المكتبات)، والحاجة إلى استجابات سريعة جدًا من النظام (المستشفيات لا تملك وقتًا لنوافذ تسجيل الدخول عندما يكون شخص ما على وشك الوفاة في غرفة الطوارئ، لذا فإنهم (في تجربتي) لا يملكون أبدًا تسجيلات دخول فريدة لكل طبيب/ممرضة/مساعد).
ونتيجة لذلك، تقع مسؤولية الأمان على عاتق التطبيقات (يجب أن ينطبق مبدأ الدفاع على أعماق متعددة على أي حال)، وعندما لا توفر إحدى التطبيقات ذلك الأمان، ببساطة لا تُستخدم لأن الأمان لا يزال مطلوبًا.
قد لا تكون بعض هذه البيئات هي الهدف الأساسي لشيء مثل Discourse، لكن يمكن استخدامها بسهولة لتسهيل العمليات في أي من هذه البيئات إذا تم إعدادها بشكل صحيح. يمكن للأطفال والكبار مشاركة المعلومات داخل فصل دراسي ضمن مجموعة محددة لذلك الفصل. ورغم أن الأشخاص في المكتبات قد لا يملكون تسجيلات دخول للمكتبة، إلا أنهم لا يزالون يستخدمون تلك الحواسيب لتسجيل الدخول إلى أنظمة مختلفة باستخدام أسماء المستخدمين وكلمات المرور الخاصة بهم (رغم أنني لن أفعل ذلك أبدًا). يمكن للمستشفيات استخدامها للاتصالات داخل المستشفى أو بين المستشفيات، ومشاركة الأفكار حول مواضيع معينة، والإجراءات، وما إلى ذلك، وفي جميع هذه الحالات يُفترض أن يكون لدى Discourse تسجيل دخول كامل لمستخدمي النشر.
في العديد من هذه الحالات، قد ينطبق أيضًا نظام تسجيل الدخول الموحد (SSO)، مما يوفر أمانًا متزايدًا وراحة عند إعداده بشكل صحيح. المشكلة هنا هي أن ملف تعريف الارتباط الدائم الافتراضي لمدة شهرين (!!) يعني أن أي شخص يأتي إلى ذلك الحاسوب في الأشهر القليلة القادمة سيحصل سحرًا على الدخول بصفت المستخدم الذي كان موجودًا آخر مرة. يمكن تقليل الإعداد إلى ساعة واحدة (1) فقط، لكن هذا لا يزال وقتًا كافيًا للمشاكل العرضية أو الخبيثة. ماذا يمكنك أن تفعل في غضون شهرين؟
إعارة حاسوبك لصديق.
تبرع به لشخص يحتاجه عندما لا تحتاجه (تبرع).
تعبك من الحاسوب، فأطفئه، وبعه على موقع eBay، وأرسله حول العالم، ليسمح لشخص آخر باستخدامه.
تعرضك لاختراق وسرقة في منزلك أو مكان عملك.
تعرض زميل لك لاختراق حاسوبك خلال الليل، مما يسمح له بالتمهيد من وسيط خارجي وسحب ملفات تعريف الارتباط الدائمة المفيدة.
أن تكون هدفًا لشخص لديه أجندة، على Craigslist أو وسائل التواصل الاجتماعي، وما إلى ذلك، ويقدم شراء حاسوبك بمبلغ جنوني للحصول على ما بداخله بموافقتك.
بعض هذه الاحتمالات قد تبدو بعيدة المنال، لكنها أيضًا سهلة ورخيصة نسبيًا. بعض الأشخاص الذين يجب أن يكونوا أكثر حذرًا قد يكونون مستعدين لـ “فقدان” حاسوب عملهم القديم لمدة ثلاث (3) سنوات، والحصول على حاسوب جديد نتيجة لذلك، مقابل 1,000 دولار من شخص ما عبر الإنترنت. قد يكتشف العديد من المستخدمين في هذه المنتديات هذه الحيلة، لكن ليس الجميع صادقون أو مستقرون ماليًا.
يُعد وصف ذلك بتهديد أمني أمرًا مبالغًا فيه إلى حد ما. فالبيئات التي تستخدم أجهزة كمبيوتر مشتركة تتوفر فيها بالفعل خيارات لضمان عدم قدرة مستخدم واحد على الدخول إلى جلسة مستخدم آخر أثناء التنقل بين الأجهزة:
أعلم فقط ببيئة عميل واحدة خلال العقدين الماضيين لم تكن الخيارات المذكورة أعلاه ممكنة فيها.