機能リクエスト: 管理者レベルのキーなしでサイト設定への安全なAPIアクセスを許可する

貢献 特徴
1

私の理解では、/site/settings.json への管理者アクセスを必須とし、/site.json にある一部の情報にアクセスすることは、Discourse の標準的な動作です。

Discussion Bridge や同様の統合機能は、日常的な診断、計画、同期のために、限られたセットのサイト構成情報が必要です。現在、これは管理者に関連付けられた API キーを使用することを必要とする場合があります。読み取り専用の管理者キーは書き込みを防ぎますが、管理者が読み取れるすべての情報を依然として公開してしまいます。グローバルな管理者キーは、日常的なマシン操作に対して不必要に大きなリスクをもたらします。

Discourse は以下のいずれかを提供できますか？

  • 非管理者の統合ユーザーに、/site.json と /site/settings.json の適切で安全なサブセットへの読み取りアクセスを付与する、細粒度の API キースコープ；または
  • 統合機能が一般的に必要とする非機密の構成情報を含む別のエンドポイント？

Discourse はすでに通常ユーザー用のユーザー API キーをサポートしていますが、これはこのケースを解決しません：キーは、関連付けられたユーザーがすでに持っている権限のみを実行できます。したがって、このリクエストは、統合機能が必要とする限られたサイト構成データへの、安全な非管理者認証を具体的に求めています。単なる別のキー生成方法ではありません。

目的は、プライベートな管理者設定を公開することではありません。権限を持つ非管理者の統合アカウントが、日常的な管理者レベルの資格情報を必要とせずに、必要なサイト構造と運用設定を確認できるようにすることです。

これにより、資格情報のリスクを低減し、最小権限の統合をサポートし、機械間ツールをより安全に運用しやすくします。

背景：Confirming API Access to Authoring Limit Site Settings

「いいね！」 3
Confirming API Access to Authoring Limit Site Settings
2

これに大賛成です！

私たちの組織には、協力したいと望んでいるメンバーがいますが、彼らが提案した実装を行うには管理者権限が必要です。そのため、権限とアクセスをより細かく範囲限定できる方法があれば、十分に実装可能な機能やサービスを提供するのが非常に困難になっています。いくつかの理由から、アクセスの付与方法に対して非常に制限的である必要があり、これが管理者に「すべてをこなす」プレッシャーをかけています。一部のメンバーが簡単に管理できる破壊的ではないサイト設定が存在するのに、彼らはそれを行うことができないのです。

この投稿をありがとう！

「いいね！」 2
3

どの具体的なサイト設定について、もう少し詳しく教えていただけますか？

すべてのサイト設定に対する無制限の読み取り専用アクセスは、少し大げさな方法に思え、SaaSキーを含む非常に機微な設定も含まれてしまいます。

特定の名称のサイト設定セットに対して、グループの読み取り専用アクセスを可能にするプラグインを作成することはできませんか？

それは比較的小さなプラグインになるでしょう。

「いいね！」 1
4

私に聞いていますか、それとも @jenmck にですか？

現在、非管理者ユーザーのアクセス権がないため、通常の手段が使えないのが現状です。そのため、このリクエストを出しました。 :slight_smile:

5

あなたにです。

何を言っているのかよく分かりません :confused: もう一度言い直していただけますか？

「いいね！」 1
6

目標は、管理者ユーザーが使用するグローバルスコープのキーや、管理者ユーザーが使用する粒度の細かいスコープのキーを使用せずに、必要な設定にアクセスして設定することで、統合の作業を行うことです。

私は依然として管理者ユーザーに接続しなければならない場合、アクセスを制限するために粒度の細かいスコープのキーはあまり役に立ちません。これが役立つことを願っています。

プラグインの使用を提案してくださったのは良いアイデアですが、現在の機能セットを持つプラグインは望んでいません。AstroユーザーがDiscourseに接続するためにプラグインをインストールする必要はないと思っています。

7

これは何ですか？また、どの設定へのアクセス権が必要ですか？

Astro ユーザーとは何ですか？

8

まだ完全に準備はできていませんが、ご質問があったので

SSG

「いいね！」 1
9

つまり、そんな大がかりな構成を構築しているなら、カスタムルートでいくつかの設定をリードオンリーで提供する小さなプラグインを作成することがなぜ大問題なのだろうか？

10

私の意見では、これに関する Discourse の動作を変更すべきです。そのため、機能リクエストを出しました。プラグインが必要だとは思いません。

プラグインなしで回避策があり、望ましくない方法ですが、動作しています。プラグインについては、追加の機能セットがプラグイン内で設定可能になる予定ですが、まだ準備中です。

私にも意味が分かりません。言葉のスパゲッティになってしまい、申し訳ありません。:grinning_face:

「いいね！」 1