これは、すべてのユーザーにランダムに発生し続けています。私自身には発生していませんが、他の誰かに発生したときに一度サインアウトさせられたことがあります。どこから調べ始めればよいのか全く分かりません。
フォーラムで公開したスレッドで、さらに詳しい情報を提供しています。今回は、2人のユーザーが同じユーザーとしてログインしてしまいました。一人は管理者で、もう一人は管理者ではありません。彼らがログインしたユーザーは、アクティブでさえありません。
@Falco どこを見ればよいか、何か insight があれば教えていただけますでしょうか。
@Falco これは数年前から続く問題です。私の知る限り、これはクライアント側のユーザーセッション、特にuserIDの問題です。ローカルログイン、つまりローカル認証の代わりにサードパーティ認証を使用すると、この問題は回避されるだけで、修正されるわけではありません。
これがあなたの不十分なローカル認証が原因であることを確認してもらえますか？
失礼ながら、インターネット上には数千もの Discourse インストールが存在します。私達のホスティングだけでも数千を運用しており、セルフホスティングも多数ありますが、あなたのインスタンスだけがこの問題を報告しています。これは、あなたの問題が最も可能性が高いのは 自己責任 であることを意味します。
Discourse の前にカスタムリバースプロキシを実行しているため、これを削除し、バグをここに報告する前に、私達が推奨する標準インストール設定に移行することから始めることをお勧めします。
私のセットアップがカスタムなのか、それとも両方ともnginxを使用しているdiscourseに組み込まれているものなのかははっきりわかりません。とはいえ、discourseは私がホストしている唯一のものではないため、削除することは現実的にできません。おそらく私の問題だと思いますが、私に起こったことが誰にでも起こり得ることでもあります。ホストしているソフトウェアに他に問題はありません。手助けを求めているわけではありませんが、他に何か問題がある場所を見つけるためのヒントがあれば、それを教えてくれる人がいるかもしれません。両方のコンテナとそれぞれのホストのログを確認しましたが、何が間違ったのかを探す場所が他にわかりません。
スレッドサイズが原因である可能性があると思いますか？オーバーフロー/オーバーランの副作用のようなものですか？
複数のスレッドで、さまざまなカテゴリで、数万件の返信に達します。
サポートが不足している理由は理解できます。私たちは支払っている顧客ではなく、私たちの中にはあまり礼儀正しくない人もいます。あなたが私を非難するのは当然だと思いますし、私も同意します。これは私が何か違ったことをしているために起こっている頭痛だと。でも、本当にリバースプロキシがこの問題の原因だと信じているのなら、これは大きなセキュリティの問題にはなりませんか？
ディスコースの内部動作について私が知らないこともありますが、私にはこれは開発者にとって関心のあることだと思えることです。
7万件以上の返信があるトピックを扱うフォーラムを運営していますが、このような問題は発生していません。例えば、Forum Jeux vidéo - Gamekult や https://forums.woot.com/latest?ascending=false&order=posts のようなサイトです。
はい、間違いなくセキュリティ問題です。しかし、この特定インスタンスでのみ発生する場合、それはDiscourseの問題ではなく、あなたのサイトのセキュリティ問題ということになりますよね？
喜んでお手伝いさせていただきます。リバースプロキシの問題を特定するために、数週間、標準的なインストールを使用してサイトを別のサーバーに移行することにご同意いただけますか？
リバースプロキシが何らかのトークンをうまく改ざんでき、Discourseがユーザーが別人になったと信じ込ませることができた場合…問題がリバースプロキシにあるかどうかは本当に重要でしょうか？これは他の場所で悪用可能な何かを示唆しないでしょうか？
繰り返しになりますが、認証がどのように機能するかについて知らないことはたくさんあります。
コスト増加のためサードパーティホスティングから移行しましたが、別の方法で対応できるかもしれません。リバースプロキシを調査します。現在、管理の容易さのためにこのコンテナを使用していますが、何か違うものを試すこともできます。
あなたが「自分だけだ」と言っていることはわかっていますし、それに反する証拠はありませんが、それが他の誰にとっても不可能であるという意味では本当にないでしょうか？
私が間違っているところを理解するために、Discourseが提供するnginxの設定を調べてみます。洞察に感謝します。
Discourse ドメインのプロキシでキャッシュが設定されていますか？
キャッシュオプションを使用しています。これは、上記のコンテナに付属する設定です。
「一般的なエクスプロイトをブロックする」オプションも使用しています。
現時点でここに書かれていることを理解できるとは思いませんが、Discourseを使い始めた頃、Discourseの前にVarnishを置いていたのですが、コンテンツが間違っているなど、おかしなことがたくさんありました。
Discourseは独自のキャッシュを行っており、リバースプロキシによるあらゆる種類のキャッシュは、非常に大きな時間の無駄遣いです。しかし、もちろん、私の非常に限られたスキルは、Big Guys™ができることとは全く異なります。
良い情報です。ここで「追加機能」を無効にできます。
ファルコがすでに何度か提案していることを基本的に行うということですね😏
彼はリバースプロキシを完全に削除するように求めていました。これは単にプロキシ設定からいくつかのものを削除することです。Discourseが内部でキャッシュを行っており、それが外部キャッシュと競合するとは知りませんでした。これは役立つ提案です。
彼が繰り返しスパムしているリンクは、私たちがすでにやっていることです。
これらの手順は、Docker互換のクラウドプロバイダーまたはローカルサーバーで機能します。
彼は標準コンテナを実行しています。ドキュメントでは「Docker互換」ボックスの使用について言及されており、彼はそれを使用しています。ドキュメントではローカルサーバーの使用についても言及されており、彼はそれを使用しています。
特別な承認済みプロキシの使用やキャッシュの無効化については言及されていません。
過去に同様の問題を引き起こしたと思われるSSOを設定するためのドキュメントもあります。
それでも、キャッシュ設定や「カスタム」リバースプロキシソリューションについては言及されていません。
少なくとも、Discourseの専門家にとってこれほど明白な潜在的な問題点を強調するために、ドキュメントを更新することをお勧めします。
キャッシュ設定については非常に注意が必要です。nginx の proxy_ignore_headers のドキュメントを完全に理解しているわけではありませんが、デフォルトでは nginx は Set-Cookie ヘッダーを含むレスポンスをキャッシュしません。この設定は、Set-Cookie ヘッダーを含むレスポンスがキャッシュされる可能性があるように動作を変更しているようです。もし、Set-Cookie ヘッダーが含まれたままキャッシュされ、それが別のユーザーに提供された場合、ユーザーアカウントが切り替わってしまう可能性があります。
理論的には、この設定はメディアファイルにのみ適用されるはずですが、URL の末尾（クエリパラメータを含む？）に一致させるのは、それを行うにはかなり安全ではない方法のように思えます。
それの使用を中止しました。ほかの人も指摘しているように、全体的にかなり悪いアイデアのようです。説明には感謝します。最初は何も問題があるとはすぐには見えませんでしたが、私は確固たる専門家ではありません。
そのキャッシュの場所ブロックは、クッキーを配信するルートと重なる部分があるかもしれません。無効にしてみましょう。
@simonkが示した説明に基づいて、これは正しいと思います。
みんなの助けに感謝します。
しばらくしてからこれを更新して、賛成か反対かを伝えるつもりです。もしそうなら、他の人にとって役立つ警告となるでしょう。