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 に関する完全な別質問です：
これは一体どうして起こるのでしょうか？おそらく：
はい、これはセキュリティ上の脅威です。新しいスレッドを作成します。
ルーク、世界全体が厳格に管理されたオフィス環境に住んでいるわけではありません。
学術機関内のオープンアクセスサイトや図書館内のマシンなどを考えてみてください。多くの人は、ブラウザインターフェースを提供することをセキュリティリスクとは見ていません。
人々がハードウェアやソフトウェアを適切に設定することでこの問題を回避できることには完全に同意します。しかし、すべての人がそのような設定を行うわけではありません。したがって、ハードウェアやソフトウェアが特定の構成になっていない場合にセキュリティ上の欠陥が存在することを認識した上で、ユーザーにフォーラムを提供することは、私たちが責任を負うことになると言わざるを得ません。
それはもっともな質問ですね。共有デスクトップ環境を一般的に利用する場所には、図書館、学校、病院などがありますが、他にもあります。ご想像の通り、主な要因としては、使いやすさへの重点（1 年生にユーザー名を覚えること自体が難しいのに、そこにユーザー名や個人名を含まず、数字や特殊文字を含むパスワードまで加えるなんて！ハハ！）、固有ユーザーの不在（図書館ではユーザー名が存在しないことが多く、それはユーザー追跡の手段になり得るため、図書館関係者の多くはこれを嫌う）、そしてシステムからの極めて迅速な応答が必要であること（救急室で患者が危篤状態にある場合、医師がログインしている時間などないため、私の経験では医師や看護師、助手ごとに固有のログインは設けられていません）などが挙げられます。
その結果、セキュリティはアプリケーション側で確保する必要があります（多層防御はそもそも適用されるべきです）。あるアプリケーションがそのセキュリティを提供しない場合、セキュリティが依然として必須であるため、単に使用されなくなります。
これらの環境のいくつかは、Discourse のようなものの主なターゲットではないかもしれませんが、適切に設定すれば、これらの環境における業務を支援するために容易に活用できます。子供も大人も、特定のクラスに特化したグループ内のクラスで情報を共有できます。図書館利用者には図書館用のログインがないかもしれませんが、それでも独自のユーザー名とパスワードで世界中のシステムにログインするためにそれらのコンピュータを使用しています（ただし、私はそんなことは絶対にしません）。病院でも、院内または病院間のコミュニケーション、特定のトピックや手順に関するアイデアの共有などに利用でき、これらのすべての場合において、Discourse は投稿するユーザーに対して完全なログイン機能を備えているものと思われます。
多くの場合、シングルサインオン（SSO）も適用され、適切に設定することでセキュリティと利便性の両方を向上させることができます。ここで問題となるのは、デフォルトで 2 ヶ月もの永続的クッキーが設定されていることです。これにより、そのコンピュータに来た誰かが、直近に使用していたユーザーとして自動的にログインできてしまいます。設定を最短 1 時間に短縮することも可能ですが、それでも偶発的あるいは悪意のある問題が発生するには十分な時間です。2 ヶ月の間に何ができるでしょうか？
これらのシナリオのいくつかは遠回しに聞こえるかもしれませんが、実際には簡単で、比較的安価です。本来ならもっと知るべき人々でさえ、オンラインの誰かから 1,000 ドルを受け取る代わりに、3 年使った業務用コンピュータを「紛失」し、新しいものに乗り換えることを検討するかもしれません。これらのフォーラムの多くの人はその罠に気づくでしょうが、誰もが正直で、経済的に安定しているわけではありません。
これをセキュリティ脅威と呼ぶのは少し大げさです。共有コンピューターを使用する環境では、ユーザーがコンピューター間を移動する際に、他のユーザーのセッションにアクセスできないようにするオプションがすでに存在します。
過去 20 年間で、上記の主要なオプションが不可能だったクライアント環境は、私が知る限り 1 つしかありません。