私も全く同じことを考えていました。
当初、検索で見つけるのに苦労したので、トピックへのリンク Category Group Review/Moderation を含めます。
いつも#announcementsカテゴリの#documentationを見つけるのに苦労しています。
「いいね！」 2
正直なところ、これはどちらにしても良い考えでしょう。管理者はすべての権限（バックアップのダウンロード、設定シークレットの表示/変更、個人情報（PII）の表示、個人メッセージへのアクセスなど）を持っているので、この範囲は狭く保つのが最善です。
完全な管理者でなくても、「高い権限」を持つための余地はたくさんあります。
「いいね！」 2
お二人ともありがとうございます。これは別個のものだと知りませんでした！
その明確化をありがとうございます。そのようなものだと知りませんでした。おっしゃる通り、今知ったので、確かに制限するでしょう。
これの制限/要件を確認し、チームに伝えました。残念ながら、自己ホストする必要があるようです。提供されているFOSSホスティングは非常に寛大ですが、要件に合致しません。
最大の要因はページビュー制限です。月5万ページビューはほとんどのFOSSプロジェクトにとって十分すぎるほどですが、私たちはそれ以上のトラフィックを生成します。メインウェブサイトは、過去7日間だけで56.47kユニークビジターから187万件のリクエストを受けました。このペースでは簡単にページビュー制限に達してしまうのではないかと懸念しています。
しかし、これを指摘していただきありがとうございます！
「いいね！」 4
これに対処する方法を見つける価値があるでしょう。サーバー上のどのユーザーがDiscourseのスタッフ（管理者またはモデレーター）であるかを知っている場合、それらのユーザーのSSOメールフィールドを実際のメールアドレスに設定することを検討してください。彼らが持っている重複するメールアカウントは、偽のメールアドレスを取得します。
スタッフがDiscourseからメールを受信できると便利なケースがいくつかあります。最初に遭遇する可能性が高いのは、Discourseがスタッフユーザー用に/u/admin-loginルートを提供していることです。そのルートは、スタッフのメールアドレスを受け入れるフォームを表示します。Discourseは、スタッフメンバーに使い捨てのログインリンクを送信します。SSOの設定に便利です。設定中に誤ってサイトからロックアウトされた場合、サイトに戻ることができます。認証サーバーに問題が発生した場合にも役立ちます。
「いいね！」 1
はい、私も同意します。Discourse の外部の理由で、私もそのことについて考えてきました。大きな問題は、一般メンバーがスタッフになることができ、実際にそうなっているという事実から生じます。そのため、スタッフユーザーにユニークなメールアドレスを要求したとしても、ユーザーがそれを持っていることを保証できないため、重複したメールアドレスを持つユーザーがスタッフメンバーになった場合に問題が発生します。
とはいえ、DiscourseConnect が最初にユーザー検索にユニーク ID を使用し、DiscourseConnect の投稿の「Discourse はメールを使用して外部ユーザーを Discourse ユーザーにマッピングします」という部分が、新しい SSO ユーザーを既存の Discourse アカウントにリンクすることのみを指していること、そしてログインプロンプトの仕組みに関する私の誤解が解消された今、重複したメールアドレスをそのまま送信することを実際に妨げているものはありますか？それとも、この一意性は厳密に強制されていますか？
はい。ログインフローの説明で手順を1つ省略していました。Discourseはまずexternal_idに基づいてユーザーを検索し、次にemailに基づいてユーザーを検索しようとします。どちらも見つからない場合、Discourseはユーザーを作成しようとします。これが、ユーザーがDiscourseに最初に登録される方法です。Discourseでは重複したメールアドレスは許可されていないため、すでに使用されているメールアドレスを持つユーザーを作成しようとすると、Discourseはエラーをスローします。
ペイロードで送信されるメールは、ユーザーごとに一意であることを確認する必要があります。
承知いたしました。明確化ありがとうございます 
後でユーザーのメールを、手動で更新することは可能でしょうか？ ログインプロンプトの問題が解決したので、チームが以前から考えていた、偽のメールと、それらをユーザーの実際のメールにマッピングするSMTPサーバーを使用するというアイデアを実装することを検討するかもしれません。例えば、すべてのDiscourseのメールをuserid@example.comのようなものに更新し、それがまずSMTPサーバーに接続してuseridを取得し、ユーザーの実際のメールを検索します。ただし、これはすぐに準備できるものではないため、後でユーザーのDiscourseのメールを更新する必要がある可能性があります。
はい。これには、サイト設定の auth overrides email を有効にする必要があります。有効にすると、ユーザーがログインするたびに、Discourse のメールアドレスが認証ペイロードに含まれるメールアドレス（この場合は DiscourseConnect ペイロード）と同期されます。無効にされている場合、ユーザーのメールアドレスはアカウントが最初に作成されたときに認証ペイロードのメールアドレスに設定されますが、その後のログインでは更新されません。
auth overrides email が有効になっていると仮定すると、sync_sso ルートに API リクエストを行うことで、ユーザーにログインを要求せずに更新することもできます。Sync DiscourseConnect user data with the sync_sso route。
サイトの Rails コンソールからユーザーのメールアドレスを一括更新することもできますが、（私の記憶が正しければ）その方法では確認メールが Discourse からユーザーに送信されます。これは偽のメールアドレスでは機能しません。
最初から意味のある値にメールアドレスを設定することもできるかもしれません。Discourse サイトがセットアップされたら、偽のメールアドレスとして受け入れられるメールドメインについてテストを実行する必要があります。私の記憶では、@invalid.com は受け入れられると思います。他のドメインについてはわかりません。あなたの方で、<userId>@invalid.com のようなものをユーザーの実際のメールアドレスにマッピングできます。
あなたは信じられないほど親切でした。本当にありがとうございます！APIソリューションは私が考えていたものですが、同期できると知っておけば完璧に機能します。
はい、できます。まずプラスアドレス指定を試してみるつもりでした。そうすれば、少なくとも一部のユーザーは最初からメールを受け取ることができます。その後、全員をサポートするために、プラスアドレス指定が機能しなかったユーザーも含めて、後で独自のSMTPマッピングサーバーに移行します。
「いいね！」 1
@simon @supermathie お二方にはこれまで大変お世話になりました。少しスレッドの範囲を離れて、追加のヘルプをお願いできないでしょうか？
開発用のDiscourseをローカルマシンにインストールしました。Install Discourse for development using Docker を参考にしました。ローカルテスト用にセットアップする方法について、他にガイドが見つかりませんでした。Wikiには本番環境のセットアップしか載っておらず、ドメイン/DNS/SMTPを事前に設定する必要がありました。すべての実装が完了するまでフォーラムを公開したくなかったので、これらが一切不要なローカルテストが必要でした。
そのガイドを使ってDiscourseを稼働させ、ローカルインスタンスのサイトにSSOを実装しましたが、現時点で2つの問題に直面しています。
return_sso_urlへのリダイレクトが半端にしか機能しないようです。私の場合はURLがhttp://localhost:3000/session/sso_loginです。リダイレクトは成功しますが、最初のredirectの後、http://localhost:3000に送信され、RuntimeError: Discourse does not support compiling scss/sass files via Sprocketsというエラーが表示されるだけです。このエラーについて見つけた唯一のスレッドは Error when building: discourse does not support compiling scss/sass files via sprockets ですが、あまり進展していないようです。OPはどの解決策も受け入れておらず、RAMとスワップサイズについて質問されただけでした（これを実行しているマシンには32GBのRAMと2GBのスワップがあります。これが問題だとは考えにくいです）。avatar_force_updateが尊重されていないようです。少なくとも管理者ユーザーに対しては？サイト設定でdiscourse connect overrides avatarを有効にし、SSOレスポンスペイロードでavatar_urlとavatar_force_updateの両方を設定しています。しかし、管理者アカウント（外部アカウントにリンクされている）にログインしても、外部のプロフィール画像が表示されません。API経由で管理者ユーザーのデータを確認すると、external_avatar_urlが正しく設定されていることはわかりますが、UIでは使用されていないようです。
そうなるはずです。SSOペイロードを生成しているアプリケーションがブール値 true を 1 に変換していないことを確認してください。それは一般的な問題です。それを回避するには、SSOペイロード内の任意のブール値を文字列 \"true\" または \"false\" に設定できます。Discourseはそれらを正しく解釈します。まずそれを確認して、問題かどうかを確認してください。他の問題である可能性もあります。avatar_force_update を処理するコードはやや複雑ですが、読みやすいです: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub
編集: SSOペイロードのブール値の問題について、SSOペイロードを生成するプロセスで、環境がブール値のtrue/falseを文字列に変換するということの方が正確だと思います。Discourseは文字列が \"true\" または \"false\" であることを期待しています。他のプログラミング環境では、それらを異なる方法で処理する場合があります。例えば：
PHP:
wp> strval(true)
=> string(1) "1"
Rubyとは対照的に:
irb(main):001> true.to_s
=> "true"
Python (Discourseがこれをどのように処理するかはわかりません):
>>> str(True)
'True'
「いいね！」 2
どちらか試してみます。その方向性を示していただきありがとうございます。しかし、それはかなり直感的ではありません。通常、人々はセットアップを「迅速かつ簡単」に行う方法として Docker ソリューションを探します。Docker バージョンを 避ける ように推奨されたのはこれが初めてです。しかし、なぜ Docker バージョンでこれが起こるのかという疑問は残ります。一時的に問題回避のために別のインストール方法を使用することはできますが、根本的な問題は解決しません。
1 に設定されているわけではありません。JavaScript で作業しており、ブール値 true は常に文字列 "true" に文字列化されます。
String(true); // 'true'
(true).toString(); // 'true'
// これは私のコードが実際に使用しているものです
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
Ruby を扱ったことがないので、実際に掘り下げてどこまでできるかわかりません。しかし、一見したところ問題は見当たりません。しかし、Discourse ダッシュボードの関連設定と SSO ペイロードの両方が設定されていることを確認しました。
標準ユーザーアカウントの画像を、アカウント作成時のもの以外に変更しようとテストしたわけではありませんが、標準ユーザーアカウントに初めてログインしたとき、Discourse はアバターをダウンロードし、期待どおりに適用しました。更新されていないのは管理者アカウントだけですか？
公平を期すために言うと、PHP では変数の「実際の」文字列表現を取得するために var_export を使用することがほとんどです。なぜなら、それはその変数を再作成するために必要な有効な PHP を返すからです。
var_export(true); // true
「いいね！」 1
ユーザー管理ページの下部にある DiscourseConnect セクションを確認してください。クリックすると、Discourse が受信した最後の SSO ペイロードの値が表示されるボタンがあります。
Rails コンソールから同じ情報を見つけることもできます。たとえば、次のようになります。
> SingleSignOnRecord.last
# または
> SingleSignOnRecord.where(external_id: 2)
verbose discourse connect logging サイト設定を有効にする必要があります。これにより、管理者 / ログ / エラーログで生成されるログに詳細が追加されます。アバターの問題については、関連するログエントリが DiscourseConnect ログではなく、通常のログとして表示される可能性があります。
問題はおそらく WordPress に固有のものです。WordPress は常に true に対して 1 を返し、true の文字列表現に対しては "1" を返します。
「いいね！」 1
これは期待されるペイロードであり、プロフィール画像のURLは正しく表示されています。
プロフィール画像はこれであるべきです。
しかし、まだ次のように表示されています。
これは私のGravatarです。
この設定を誤解しているか、他に設定する必要があるものがない限り、これらの設定を上書きする設定を有効にしました。
キャッシュの問題を排除するために、シークレットモード、異なるブラウザ、ブラウザキャッシュのクリアも試しました。
これはローカル開発サイトでのことですか？
アバターのアップロードが何らかの理由で失敗したのではないかと考えています。verbose discourse connect logging というサイト設定を有効にしてから、ログアウトして再度ログインしてみてください。ログにはアバターに関連するメッセージが少なくとも1つ表示されるはずです。
アップロードの失敗に関連する別のエラーが表示される可能性もあります。
まだお気づきでない方のために説明すると、これは「ブラウザから直接アクセスするのではなく、ember-cli プロキシ経由でアクセスしなければならない」ということです。
開発用に起動するには bin/ember-cli -u を使用してください。
アバターの状況は再現しました。
変更前：
ログインペイロード：
変更後：
しかし：
これは、Discourse がカスタムアバター URL を正しく設定しているものの、Gravatar からカスタム画像に切り替えていない バグだと思われます。
新しいユーザーを作成した場合：
すぐに機能します：
したがって、これは DiscourseConnect を使用する 前に Gravatar が設定されたアカウントによってトリガーされていると疑われます。
「いいね！」 2
Ubuntuの手順は（すでにインストールされているパッケージやソフトウェアとインストーラーが競合していたため、かなりの調整が必要でしたが）機能させることができました。これにより、最初に発生していたエラーは解消されましたが、SSOはまだ半分しか機能していません。SCSS/Sassのエラーの代わりに、SSOは毎回「アカウントのログインがタイムアウトしました。再度ログインしてください。」というエラーが表示されます。このエラーページで「ログイン」ボタンを2回クリックすると、ログインが完了します。私の側ではコードの変更はなく、Discourseの実行方法が変わっただけです。
これはローカルで実行することの奇妙な点として片付けようと思います。本番環境のデプロイでは、これらの問題が発生しないことを願っています。
Dockerバージョンではこれは何も効果がないようでした。スクリプトは何も出力せずに終了し、Discourse側では何も起こっていないように見えました。また、これはDockerガイドに記載されている手順とも矛盾しており、奇妙に感じます。これについて記載されていない理由はあるのでしょうか？
Dockerメソッドにこれらの問題があるように感じられ、公式のアドバイスがDiscourseをネイティブにインストールすること（インストールスクリプトがbashrcの使用などを想定しており、すでにインストールされているパッケージの競合する可能性のあるバージョンをインストールしようとするため、常に問題なく動作するわけではないにもかかわらず）であるのは奇妙に思えますか？利用可能なすべてのホスティングバージョンに関する潜在的な問題について、警告が必要なのでしょうか？一見しただけでは、どれを選択すべきかは明らかではなく、通常、Dockerビルドが利用可能であればそれが最善の方法であると人々は想定します。
私だけではなかったと聞いて嬉しいです！
バグは決して楽しいものではありませんが、このバグを見つけるのに貢献できたことを嬉しく思います。
その可能性もありますが、DiscourseConnectは問題なくローカルで動作するはずです。Discourseにhttp://localhost:4200でアクセスしていますか？ローカル開発環境では、Discourseにlocalhost:4200または127.0.0.1:4200のいずれかでアクセスできるという奇妙な（私にとっては）問題があります。localhostドメインを使用することをお勧めします。127.0.0.1とは異なるセッションとして扱われます。
いずれにせよ、これは単なる推測です。詳細については、詳細ログ設定を有効にしてログを確認してください。
インストール手順では、スクリプトを実行する必要がないことが明確に示されているはずです。すべての依存関係がインストールされていることを確認するために、スクリプトをステップバイステップで実行することができます。
はい、そうです。
以前リンクされたものには、その旨は明記されていませんでした。私は Set up a local Discourse Development Environment? にアクセスし、Ubuntu 22.04.3 を実行しているので Install Discourse on Ubuntu or Debian for Development を選択しました。このページには、スクリプト全体を実行する必要はないと書かれていますが、それはユーザーに実行を指示する部分の 直後 の小さなテキストにすぎません。
私にとっては、これは明確ではありませんでした。なぜなら、指示を上から順に読むと、次のステップに進む前に現在のステップを完了する必要があると自然に考えるからです。そのため、私はインストールスクリプトと格闘し、必要なものだけをインストールしましたが、完了後に読み進めると、それが最初から意図されていたことであり、実際には何も格闘する必要がなかったことに気づきました。
その免責事項を指示の 後に 置くことは、私の意見では、決して明確ではありません。
「いいね！」 1
ノンス（nonce）が間違っているようです。ログイン時にログに次のように表示されます。
CSRFトークンの認証に失敗しました。午後3時44分
詳細SSOログ: SSOプロセスを開始しました add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 午後3時44分
詳細SSOログ: ノンスが間違っています。別のブラウザセッションで生成されたか、期限切れです add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 午後3時44分
詳細SSOログ: SSOプロセスを開始しました add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 午後3時44分
詳細SSOログ: ユーザーがPN_Jonでログインしました add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 午後3時44分
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb) が見つかりませんでした: そのようなファイルやディレクトリはありません @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 午後3時44分
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb) が見つかりませんでした: そのようなファイルやディレクトリはありません @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 午後3時44分
さらに調査したところ、SSOリダイレクトでlocalhostが使用されておらず、127.0.0.1にリダイレクトされていることが原因のようです。最初にlocalhostを使用する代わりに127.0.0.1を使用するように切り替えると、問題は解決します。