例えば、テーマ機能への管理者またはモデレーターのアクセスを許可するが、ソーシャルログインからのAPIシークレットの表示へのアクセスは無効にする、といった例が挙げられます。
また、モデレーターを分離することもできます。例えば、フォーラムのコミュニティブランチにモデレーターロールを付与し、コミュニティからの信頼できるユーザーに制限付きで権限を与える、といった例です。
「いいね！」 1
こんにちは 
私の理解が正しければ、Discourseがモデレーターの権限を提供しているかどうかを尋ねているのだと思います。
もしそうであれば、それは不可能です。あなたは、スタッフ（管理者またはモデレーター）、カテゴリモデレーター、またはTL4リーダーのいずれかです。
こちらのトピックをお読みください。
カテゴリモデレーターまたはリーダーがここでうまく機能すると思います。
テーマへの書き込み権限を持つユーザーは、ユーザーセッションを完全に乗っ取ることができます。そのようなユーザーを信頼できない場合は、まったく信頼すべきではありません。そして、信頼できる場合は、単に管理者にするだけで済みます。
「いいね！」 1
これは例として、APIキーへのアクセス権を付与したくないが、他の設定セクションには付与したいということです。管理者がそのキーをコピーして、将来的にテストなどのために別の場所で使用することを防ぐためです。
必ずしも悪意のある意図があるわけではありませんが、例えばGitHubキーの場合、これは非常に懸念されるセクションです。管理者はリポジトリとは全く関係がないかもしれませんが、必要であればフォーラムを管理することもあります。しかし、単に「コピーして盗まれる」というだけで、彼が誤ってキーを危険にさらすことを望みませんでした。
あるいは、間違いで削除してしまうこともあります。
自分のキーを取得するのが面倒なため、またTwitterやGoogleの場合は、それらのキーはもはや「アクセスが欲しい」と書いたすべての人に配布されているわけではないため、すべてがかなり矛盾しています。キーの偶発的な漏洩でさえ、APIへのアクセスが無効になる可能性があります。
将来必要になった場合に、そのようなソリューションページを追加のパスワードで保護するにはどうすればよいですか？
たとえ可能性が低いとしても、考えられるすべての脆弱性について考え、予防することが最善だと思います。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.