スティーブン、あなたの考えは理解できますが、これは過剰な警戒ではありません。
IT 担当者は毎日、知識のない人々やいわゆる「無知なユーザー」と向き合っています。あらゆる事態に対処できるシステムを構築しようとしますが、それは容易ではありません。現在、ID 管理は大きな課題です。この問題に気づけたのはテストのおかげですが、特にこの件は 2016 年から議論され（修正もされた）ていることを考えると、事前の連絡があれば助かりました。
私が何かを見落としているか、設定ミスがあることを願っていましたが、実際には設計通りに動作していることがわかりました。今後は、この問題を回避するための外部対策を検討し、ユーザー向けにドキュメント化します。将来的には、Discourse 側でこの問題の解決に向けた圧力が高まることを願っています。
でも、ユーザーがブラウザを閉じるのを忘れたらどうなるのでしょうか？その場合どう動くのですか？
ただ、@falco さん、2016年のパッチが却下された理由が気になります。それは安全ではない変更だったのでしょうか？
いくつかの妥当な指摘ですね。
ただ、いくつかの例にはかなり驚かされました。
病院：ここ数年私が利用した病院では、間違いなく独自のロックアウト機能があります。看護師が採血の作業中に数秒離れただけで、再度ログインを求められるほどです。
救急外来では、緊急に関連するデータにアクセスできる専門システムがあるかもしれませんが、個人情報（PII）や部署内のチャットフォーラムへのアクセス権は持っていないはずです。
図書館：
私の住む地域のすべての公立図書館（ごく小さな町や、ITに詳しくないスタッフがいるところも含めて）では、共通のログインIDが使用されています（すべての利用者が同じで、モニターに貼ってあります）。また、離席時に自動再起動するポリシーがあり、子供を含むすべての利用者がこれに従うことが求められています。再起動の過程では、ブラウザの履歴、キャッシュ、クッキーが自動的にクリアされます。
ディスカッション側でもっと慎重なポリシーを採用することが悪いことだと言っているわけではありません。このトピックで挙げられている「きっかけ」となる状況のいくつかは、私が懸念を抱かせる理由です。なぜなら、フォーラム投稿の誤った帰属付けは、彼らが抱える問題のほんの一部に過ぎないからです。
タイムラインは以下の通りです。
2012 年～2016 年 5 月：Discourse のセッションクッキーは常に永久に設定される
2016 年 5 月～2016 年 7 月：Discourse のセッションクッキーはデフォルトで永久に設定されるが、サイト設定によりブラウザを閉じた際に無効化可能
2016 年 7 月～現在：Discourse のセッションクッキーは 1440 時間に設定され、使用時に更新される。サイト設定で最大有効期間を制御可能。ブラウザセッションクッキー設定は削除された。
主に以下の理由で削除されました。
世界中のいくつかの地域では、他人とコンピュータを共有するという概念は非常に異質で、特にモバイル個人端末や現在のような COVID-19 の状況ではなおさらです。しかし、学校図書館や職場など、ある場所では非常に一般的です。
ほとんどの場合、使用後にコンピュータを電源オフにします。コンピュータを電源オフにするとブラウザも閉じられるため、結果的にウェブアプリでのログインセッションが終了します。
次の従業員が次のシフトでコンピュータを起動すると、ブラウザにはセッションベースのクッキーは残っていません。
その通りですが、この値を 0 に設定することで、可能であれば（サポート上の問題が過度に増えたり、技術的に難しすぎたりしない限り）、「クッキーがブラウザセッションの間のみ有効」という動作を実現できるようにすべきだと考えます。そのため、サイト設定の説明にもその旨を明記できるようにします。
最大セッション期間 [デフォルト 1440 時間]
ユーザーは前回のアクセスから n 時間ログイン状態を維持します。0 に設定すると、ブラウザを閉じた時点でログアウトされます。
病院：私が共有するのは、経験に基づいて確実に行われていることだけです。画面がすぐにロックされることに同意しますが、それはブラウザからのログアウトではなく、ましてや OS のユーザーからのログアウトではありません。ある人が死に直面している間に、医師や看護師が何らかのアプリケーションを起動して作業を行う前に、コンピューターがログインし、ポリシーを適用し、ネットワーク接続を設定しなければならない状況を想像してみてください。同様に、ログインは通常、ユーザー名とパスワードではなく、同じ理由からバッジと短い PIN の組み合わせで行われます。救急室（ER）、手術室（OR）、およびその他の多くの部屋では、患者情報の記録が必要であるため、私が携わった現場では、どこでも一貫した運用がなされていました。
図書館：ログアウト時に再起動するポリシーは存在し、管理者がボックス上のすべてのキャッシュを手動でクリアする限り効果的ですが、そうでない場所も数多く見かけました（その理由の一つとして、私は一度も自分の資格情報で共有ワークステーションを使用したことがありません）。同じ不運な設定をホテルやインターネットカフェ（またはコーヒーショップ）でも頻繁に見かけます。
すべてのインストールで全ユーザーに対して、あるアプリケーションがデフォルトでこの設定を採用するとは奇妙に思えます。セキュリティは、多くの人が最初にコンピューターを設定する際の焦点ではなく、一般的に複雑であるため、専門家のフルタイムの仕事となっています。公衆向けにコンピューターを設定する人々は、もっと良く知るべきですが、ブラウザにはセッションクッキーという概念があり、アプリケーション開発者がユーザーにとって直感的なセッションを実現しやすくしています。
多くのサイトがセッションをタイムアウトさせ、ブラウザを閉じるとセッションを破棄するにもかかわらず、ユーザーがログアウトするために手動でサイトのクッキーをクリアしなければならないと理解することを要求するのは、あまりにも多くを求めているように思えます。代替手段を全く認めず、ユーザーが特定の Discourse のログアウトリンクを使用することを思い出させなければならない場合、ユーザーが何らかの理由でそのリンクを見逃すと問題になります。思い付く限りでは以下の通りです：
また、ログインの持続期間が 2 ヶ月も続くのは、本当に長すぎると感じます。他のサイトでは最近そのような設定をしている場合や、さらに長い場合もありますが、ユーザーは通常、「公共のコンピューター」チェックボックスでこれらを制御できます。ただし、SSO ではこれが適用されないか、あるいは全く適用されないかもしれません（私は Discourse の専門家ではありません）。
単に考慮すべき追加の意見です。
私も同じ問題に直面しており、どのように解決すればよいかわかりません。
@codinghorror ありがとうございます。この件を評価し、実装するためのプロセスとタイムラインはどうなりますか？
わかりません。変更の技術的な難易度によります。@sam 上記の投稿で提案されている内容（https://meta.discourse.org/t/session-timeout/34686/45）の難易度について、あなたの考えをお聞かせください。
これってすごくいい機能だと思います。誰が実際にオンラインで、誰が単に放置されているのかがわかるようになりますから。
ここには新しいサイト設定を本当に追加する必要があります。概念的に結合が解かれているため、コードの理解が難しくなるからです。
具体的には、ここで最小値を追加する必要があります。
また、コードが正常に機能し続けるようにするために、いくつかの他の場所でも追加する必要があります。
必要なのは、「ブラウザを閉じたときにユーザーを自動的にログアウトする」という明確な設定です。
セッション長は、セッションクッキーを使用する場合（つまり、expires を省略する場合）でも適用されます。
例えば、以下のように設定できます。
これらは異なる問題です。
persistent_sessions を追加して、デフォルトを true にするのはどうでしょうか？「true に設定すると、ブラウザを閉じてもセッションが維持される」という意味です。この変更は約20分で完了します。
別々のサイト設定の方が優れており、20 分程度の簡単な変更で済むなら、ぜひそれで行きましょう。
将来的には、この良いアイデアが「サイトごと」の設定だけでなく、「ユーザーごと」の設定にも拡張されることを期待しています。
これは現在、サイトごとの設定として実装されています。
https://review.discourse.org/t/feature-add-support-for-not-persistent-sessions/15171
これは本当に管理者の選択だと思います。これはセキュリティ機能です。長期的には、この制限を回避する IP アドレスの許可リストを検討するかもしれません（例えば、社内ネットワークのコンピュータはログイン状態を維持し、外部のコンピュータは自動的にログアウトされるようにする）
このリクエストの性質上、これはユーザーごとの機能だと考えられます。
自宅やオフィスで自分のコンピュータを使用しているユーザーは、クッキーの期限切れを必要としないため、その選択はユーザー自身に委ねるべきです。
一方、カフェなどの共有コンピュータを利用する「ノマド」タイプのユーザーは、セッションの自動期限切れを希望するでしょう。
この機能の本質はユーザーアカウントのセキュリティにあるため、この設定は通常、ログイン時にユーザー設定やチェックボックスとして実装されています。
例えば、vBulletin では 10 年以上前からこの機能が標準搭載されており、ログイン時に「ユーザー」がセッションを維持したい場合にチェックボックスを選択するだけで済みました。
「セキュリティ」はユーザーアカウントに関するものであるため、過去には通常、ユーザーごとの設定として実装されていました（参考まで）。
追記：ユーザーが特権アカウント（管理者、モデレーター、リーダーなど）の場合、サイト全体のセキュリティというより大きな問題も生じます。
多くのサイトでこの実装を見たことがあります。一般的な実装は以下の通りです：
30 日間ログイン状態を維持する
[ ログイン ]
いつ実装されるかはまだ分かりませんが、実現する際には、おそらくこの機能を有効にするためのサイト設定が必要になるでしょう。ソーシャルログインが有効になっている場合、このようなチェックボックスをどこに表示するかという複雑な問題もあります。
みなさん、ご協力とご理解をいただき、心から感謝申し上げます。
ありがとうございます。
そうですね、行動追跡の問題から、ソーシャルログインは「私たちの得意分野」ではありませんでした。そのため、私の視点は、ソーシャルログインのサポートというより大きく複雑な要件を抱えるあなた方の視点よりもはるかに狭くなっています。
チームの皆様のご尽力に感謝します。素晴らしい仕事です。
まず第一に、迅速な修正をいただき、誠にありがとうございます。ただ一点、ご質問がございます。これを特定のデフォルト値を持つユーザーごとの設定とし、ユーザーが設定からオプトアウトできるようにすることは可能でしょうか。
これは、より多くの労力を要し、またいくつかの厄介な UI 設計上の問題があるため、上記で将来の作業として検討された内容そのものです。
さらに、この機能をしばらく利用可能にし、実装方法に技術的な問題がないか確認したいと考えています。