# Discourse のメンバーがログアウトされる - 修正方法は？
**URL:** https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514
**Category:** Support
**Created:** [2020 年 5 月 24 日午前 10:46 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514 "2020-05-24T10:46:48Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@pnoeric](https://meta.discourse.org/u/pnoeric)
#### Post date: [2020 年 5 月 24 日午前 10:46 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/1 "2020-05-24T10:46:48Z")
こんにちは。私のフォーラムのメンバー数名が、20〜30 分後に自動的にログアウトされてしまうという報告を受けています。
SSO を使用しているため、以下のようなフローで問題が起きているのではないかと考えています。メインサイトにログインし、Discourse に入ると（そこで新しいセッションが開始される？）、その後メインサイトに戻ると（Discourse はアイドル状態になる）、再び Discourse に入ると何らかの理由でログアウトされてしまう、と。
（しかし、これは少し理にかなっていません。Discourse にアクセスするたびに「アイドルタイムアウト」が 0 にリセットされるはずだからです。）
メタフォーラムでタイムアウトに関するスレッドをいくつか見つけましたが、明確な答えは見つかりませんでした。
質問：メンバーが X 時間アイドル状態になるまでログアウトされないようにする設定はありますか？それが見つかりません。
Discourse の設定で「最大セッション期間」を 1 時間に設定しているのは確認できましたが、SSO 実装においてはこれが実際には関係ないのではないかと思っています。（なお、メンバーがメインサイトからログアウトする際は、整合性を保つために Discourse へ /logout メッセージを送信しています。また、メンバーが Discourse でどのような活動を行っても、メインサイト上の最終活動時刻を更新しているため、メインサイト側のタイムアウトが原因ではないはずです。これが正常に機能しているか確認するために、現在追加のデバッグコードを追加しています。）
ありがとうございます
E
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020 年 5 月 24 日午前 10:52 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/2 "2020-05-24T10:52:56Z")
> [@pnoeric](#):
>
> 「maximum session age」を1時間に設定しましたが、SSO 実装では実際にはあまり意味がないと思うのですが、違いますか？
SSO にも適用されますので、おそらく問題の原因はそこにあるでしょう。1 時間無操作が続くと Discourse のセッションが終了し、ユーザーは再度 SSO で認証を行う必要があります。
---
### Author:  [@pnoeric](https://meta.discourse.org/u/pnoeric)
#### Post date: [2020 年 5 月 24 日午前 10:59 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/3 "2020-05-24T10:59:09Z")
問題ありませんし、完全に正常な動作です。1 時間の非活動後にはログアウトされるはずです。
問題は、20〜30 分でログアウトされるという報告が寄せられていることです。
その 1 時間のアイドルタイムアウトに関する設定はありますか？最初の投稿でも述べたとおり、それが見つからないのですが、まずはそこを確認するのが妥当だと思われますよね？
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020 年 5 月 24 日午前 11:09 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/4 "2020-05-24T11:09:40Z")
最も明らかな原因を除外するために確認ですが、時間が正確でなかった可能性はありませんか？30 分と 1 時間はそれほど違いませんしね 😉
このデバッグを続けるためには、次に `user_auth_tokens` テーブルと `user_auth_token_logs` テーブルで利用可能なデータを確認することをお勧めします。これらには、セッショントークンと有効期限に関するすべての情報が含まれています。
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020 年 5 月 24 日午前 11:10 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/5 "2020-05-24T11:10:16Z")
> [@pnoeric](#):
>
> その1時間のアイドルタイムアウトの設定はありますか？
はい、OP であなたが言及していたものです。
> [@pnoeric](#):
>
> 私の Discourse の設定で、「最大セッション期間」を1時間に設定しています
---
### Author:  [@pnoeric](https://meta.discourse.org/u/pnoeric)
#### Post date: [2020 年 5 月 24 日午前 11:10 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/6 "2020-05-24T11:10:35Z")
同意します 😉 今すぐテストしています。サイトにログインして、フォーラムに移動し、そのままブラウザを放置しています！
データベーステーブルに関するアドバイスありがとうございます。さらに調査します。
---
### Author:  [@pnoeric](https://meta.discourse.org/u/pnoeric)
#### Post date: [2020 年 5 月 24 日午前 11:18 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/7 "2020-05-24T11:18:17Z")
ふむ。ユーザーがフォーラムを利用し、トピックを読むなどして、投稿の作成（create\_post）、トピックの作成（create\_topic）、投稿の編集（edit\_post）など、何らかのアクションを起こすと、Webhook を通じて通知が届きます。これにより、メインサイトはユーザーがまだアクティブであると判断し、セッションの「最終クリック」値を更新してログアウトを防ぐことができます。これは本来の動作通りで、問題ありません。
しかし、メンバーが単にメッセージを読み続けているだけの場合、Discourse のアイドル時間はリセットされます（これは良いことです）が、_メインサイトにはユーザーがアクティブであることを示す Webhook メッセージが一切届きません_。そのため、1 時間何のアクションも取らないと（フォーラムに行って PC から離れてしまったように見える）、メインサイトはユーザーが切れたと判断し、ログアウトしてしまいます。
ここにはロジック上の穴があるように思えます。適切な SSO 実装を行うのであれば、Discourse からユーザーのセッションがアクティブかどうか（単に閲覧しているだけでも）を通知する仕組みがあるべきではないでしょうか？例えば、メンバーがアクティブだが他の Webhook メッセージを生成していない場合に、5 分ごとにピングを送信するなどの対応が考えられます。
あるいは、私のサイト側でユーザーのタイムアウトを判断した時点で、Discourse に問い合わせて、そちらでユーザーがアクティブかどうかを確認する方法もあるかもしれません。そのようなことは可能でしょうか？（[Is there an endpoint to check if a user is logged in - #3 by pfaffman](https://meta.discourse.org/t/is-there-an-endpoint-to-check-if-a-user-is-logged-in/72780/3) という記事を見つけましたが、これが求めているものかどうかはっきりせず、`/session/current.json` は API ドキュメントに記載されていません。）ただし、これでは API 呼び出しが膨大になってしまいます。私のサイトでは、アイドル状態により毎分約 15〜20 人のユーザーをログアウトさせているため、その都度呼び出しを行うことになり、Discourse ID のローカルキャッシュがない場合はさらに多くの呼び出しが必要になる可能性があります。
皆さん、どのようにお考えですか？アドバイスをお願いします。
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020 年 5 月 24 日午前 11:35 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/8 "2020-05-24T11:35:16Z")
> [@pnoeric](#):
>
> ユーザーがそこでアクティブかどうかを確認できますか？その方法はありますか？
すべてのプロフィールエンドポイントには last\_seen 値があり、これを使用できます。
> [@pnoeric](#):
>
> 適切な SSO 実装のためには、Discourse がユーザーのセッションがアクティブかどうか（単に閲覧している場合でも）を通知する仕組みが必要ではないでしょうか？おそらく、メンバーがアクティブで他の webhook メッセージを生成していない場合でも、Discourse は 5 分ごとに ping を送信すべきかもしれません。
私は SSO プロトコルでこのような設定を見たことがなく、このような機能のリクエストも受けたことがありません。一般的には、2 つのシステムを独立して運用するのが普通です。
本当に「ユーザーが閲覧した」ための webhook を作成したい場合は、カスタムプラグインを使って実現できるかもしれません。
---
### Author:  [@pnoeric](https://meta.discourse.org/u/pnoeric)
#### Post date: [2020 年 5 月 24 日午後 12:46 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/9 "2020-05-24T12:46:43Z")
> [@david](#):
>
> SSOプロトコルでこのような設定を見たことがありませんし、このようなリクエストも受けたことがありません。一般的には、2つのシステムを独立して運用するのが普通です。
「2つのシステムを独立して運用する」とはどういう意味でしょうか？私が提示した問題を解決する明らかな方法を見落としているかもしれませんので、もしそうであれば教えてください！
それ以外の場合、私の選択肢は以下の通りです：
1. メインサイトでユーザーがタイムアウトする前にログアウトせず、Discourseに呼びかけてlast\_seen値を確認し、メンバーが実際にフォーラムで活動しているか（ただし、Webhook呼び出しを生成するアクションは行っていない）を確認する。 **利点：** 実装が容易。 **欠点：** API呼び出しが大量に発生し、すでにこの点で苦労しており、レート制限を回避する対応に追われています。
2. 自分専用のプラグインを作成し、定期的にメインサイトにPingを送信することで、メインサイト上のユーザーの最終アクティビティ時刻を更新する。 **利点：** 「正しい」解決策（プッシュメッセージでアクティビティを示す）のように感じられる。ある程度エレガント。 **欠点：** 実装が容易ではない。
3. メインサイトのログアウト時間を2時間に変更する。 **利点：** 実装が容易。 **欠点：** 何かありますか？
4. 気にしない。ユーザーはDiscourseセッションの途中でログアウトされ、激しく不満を漏らします。これが現在の状況です。😉 **利点：** 実装が容易、笑。 **欠点：** ユーザーエクスペリエンスが非常に悪い。
何か見落としていませんか？
#3がよい答えのように思えますが、メインサイトでログアウト時間を長くすることの波及効果について考える必要があります。
#1が最善の選択肢だと考えていますが、その場合、これほど多くのレート制限の問題をどう防ぐかを決めなければなりません。Discourse（およびnginx、DiscourseのDockerインストールを使用しているため）ですべてのレート制限をグローバルに無効にする方法があればいいのですが、完全に無効にしたいのです。私はそれらを必要としていません。メインサイトからDiscourseインスタンスへの通信のみです。ユーザーAPIキーは許可しておらず、システムAPIキーを持っているのは私だけです。完全に閉じたシステムであり、レート制限はただ（常に）私の邪魔をしているだけです。これは別の話題かもしれませんが。
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [2020 年 5 月 24 日午後 1:55 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/10 "2020-05-24T13:55:02Z")
ご提示いただいた動作を維持する必要がある場合は、はい、それら 4 つのオプションが該当すると思います。ただし、動作を少し変更すれば、利用可能なツールとの相性がより良くなるでしょう。
あなたの設定で特異な点は以下の通りです：
> [@pnoeric](#):
>
> メインサイトでのメンバーのログアウト時に、Discourse へ /logout メッセージを送信しています
メインサイトでのセッションが切れるたびに Discourse のセッションを終了させています。この部分を削除すれば、設定は一般的な構成と一致するようになると思います。
ユーザーがメインサイトから **明示的** にログアウトする際に /logout を呼び出すことは可能です。ただし、セッションが自然に切れた際には呼び出さないようにしてください。
---
### Author:  [@bts](https://meta.discourse.org/u/bts)
#### Post date: [2020 年 5 月 24 日午後 4:48 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/11 "2020-05-24T16:48:24Z")
> [@pnoeric](#):
>
> 皆さん、どう思いますか？また、何かアドバイスはありますか？
元の投稿からは判断できませんが、超機密情報を共有する専門性の高いサイトを運営しているのか、それとも多くのユーザーが共有された公共のコンピューターからログインしているような状況なのでしょうか？
現状、最もシンプルな解決策は、ユーザーセッションの切捨てや強制ログアウトを過度に積極的に行わないことのように思えます。ユーザーとしての私の希望は、常に「明示的にログアウトボタンをクリックしない限り、_決して_ログアウトさせないでほしい」というものです。それが不可能なら、せめて1日や1週間など、もう少し長い期間に設定することはできませんか？
---
### Author:  [@pnoeric](https://meta.discourse.org/u/pnoeric)
#### Post date: [2020 年 5 月 25 日午前 7:51 UTC](https://meta.discourse.org/t/discourse-members-being-logged-out-how-to-fix/152514/12 "2020-05-25T07:51:49Z")
> [@david](#):
>
> あなたのメインサイトでのセッションが期限切れになると、Discourse のセッションも常に終了してしまいます。この部分を削除すれば、一般的な設定と一致するはずです。
>
> ユーザーがメインサイトから **明示的** にログアウトする場合は、引き続き `/logout` を呼び出せば問題ありません。ただし、セッションが自然に期限切れになる場合は呼び出さないようにしてください。
なるほど、それは良い解決策ですね。ログインページにある「ログイン状態を保持する」チェックボックスを利用するメンバーが十分にいるので、彼らをメインサイトにスムーズに戻せると思います。もしメインサイトでのセッションが期限切れになっていれば、その時点で（見えない形で）自動的に再ログインされるはずです。ふむ。
> [@bts](#):
>
> OP からでは判断できませんが、極めて機密性の高い情報を共有する専門的なサイトでしょうか？それとも、多くのユーザーが共有の公共コンピューターからログインしているような状況でしょうか？
プライバシーに非常に敏感な層を対象としたサイトです。ただ、おっしゃることは理解できました。あなたと David の提案通りに対応できそうです。
**二人とも、本当にありがとうございます。** ここでの「全体像」や、他のサイトがこの種のシナリオをどのように扱っているのか、以前はよくわからなかったのですが、今は理解できました 🙂 私の状況にもいくつかの解決策が見えてきました。心から感謝しています！