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
我找不到关于此问题的最新信息。会话最长期限的最小可设置值为 1 小时。
这在计算机被共享使用的环境中毫无用处。
最近是否有任何解决该问题的更新？本质上，我需要当浏览器关闭且用户通过 SSO 登录后，用户会话被自动清除。
谢谢
这正是我的补丁所做的，但它被回退了 
你可以查看代码并将其移植到一个插件中。
一个完全与 Discourse 无关的问题：
这到底是怎么发生的？按理说：
好的，这是一个安全威胁——我将开启一个新线程。
Luke，全世界并非所有人都生活在严格管控的办公环境中。
例如，学术机构内的开放访问站点以及图书馆等场所的计算机设备。许多人并不认为提供浏览器界面构成安全风险。
我完全同意，用户本可以自行配置其硬件和软件以避免此类问题，但并非所有人都会进行这样的配置。因此，如果我们为用户提供一个平台，而我们明知若其运行的硬件和软件未按特定方式配置则存在安全漏洞，那么我认为我们对此负有责任。
这是一个很合理的问题。通常采用共享桌面体验的环境包括图书馆、学校和医院，当然还有其他场景。正如您所想象，推动因素包括：对易用性的重视（让一年级学生记住用户名已经够难了，现在还要加上一个不包含用户名或个人姓名、且包含数字和特殊字符的密码？哈哈！）、缺乏唯一用户（图书馆通常不设用户名，因为这可能构成用户追踪，而许多图书馆从业者对此颇为反感），以及系统必须提供极快响应速度的要求（医院没有时间在急诊室有人生命垂危时等待窗口登录，因此根据我的经验，医生、护士和助理通常都没有各自的唯一登录账号）。
因此，应用程序自身必须具备安全性（纵深防御原则本应始终适用）。如果某个应用无法提供足够的安全保障，它就不会被使用，因为安全性仍然是必需的。
这些环境中的某些可能并非 Discourse 的主要目标用户群，但只要配置得当，Discourse 完全可以用于支持上述任何环境中的运营工作。例如，儿童和成人可以在特定班级的小组内共享班级信息。虽然图书馆用户可能没有图书馆专属登录账号，他们仍会使用这些电脑，用自己的用户名和密码登录各种系统（尽管我绝不会这样做）。医院可利用 Discourse 进行院内或院际沟通，围绕特定主题、操作流程等分享想法。在所有这些场景中，Discourse 很可能要求发帖用户进行完整登录。
在许多情况下，单点登录（SSO）也可能适用，在正确配置的同时提升安全性和便利性。但这里存在一个问题：持久化 Cookie 默认设置为两个月（！！），意味着接下来几个月内任何使用该电脑的人都会神奇地以最后使用该电脑的用户身份登录。虽然该设置可缩短至仅一小时，但这仍足以引发意外或恶意问题。在几个月的时间里，人们能做出什么呢？
其中一些情形听起来似乎牵强，但它们实际上既简单又成本相对较低。有些本应更明智的人，可能愿意“丢失”他们使用了三年的工作电脑，以换取网上某人提供的 1000 美元，从而获得一台新电脑。许多在这些论坛上的人或许能看穿这种伎俩，但并非所有人都诚实或经济宽裕。
将此称为安全威胁有些危言耸听。在共用电脑的环境中，已有多种选项可确保用户在切换电脑时无法进入其他用户的会话：
在过去二十年中，我只知道一个客户端环境，其首选方案无法实现。