philh
1
据我了解，要求对 /site/settings.json 和 /site.json 中的部分信息拥有管理员访问权限，是 Discourse 的预期行为。
Discussion Bridge 及类似的集成工具需要一组有限的站点配置信息，用于常规的诊断、规划和同步。目前，这可能需要使用与管理员关联的 API 密钥。只读管理员密钥可以防止写入操作，但它仍然可以暴露管理员有权读取的所有内容。全局管理员密钥在日常机器操作中带来了不必要的巨大风险。
Discourse 能否提供以下任一方案：
- 一种细粒度的 API 密钥范围，为非管理员集成用户提供对
/site.json 和 /site/settings.json 中适当且安全的子集的只读访问权限；或
- 一个包含集成工具通常所需的非敏感配置信息的独立端点？
Discourse 已经支持普通用户的用户 API 密钥，但这并不能解决此问题：密钥只能行使关联用户已有的权限。因此，本请求 specifically 要求对集成工具所需的有限站点配置数据进行安全的非管理员授权——而不仅仅是另一种生成密钥的方式。
目标并非暴露私有的管理设置。而是让经过授权的非管理员集成账户能够检查其所需的站点结构和运营设置，而无需使用常规的管理员级别凭证。
这将降低凭证风险，支持最小权限集成，并使机器对机器工具更易于安全运行。
背景：Confirming API Access to Authoring Limit Site Settings
3 个赞
jenmck
(jen)
2
对此表示强烈支持！
我们组织中有一些成员非常乐意提供帮助，但他们所提议协助实施的工作需要管理员权限。这使得我们很难提供所有本可以很好地实现的功能和服务，除非我们有一种更细粒度地划分权限和访问范围的方法。出于多种原因，我们必须对权限授予保持非常严格的限制，这增加了管理员“包揽一切”的压力，尽管有些非破坏性的站点设置本可以由我们的一些成员轻松协助管理……但他们却无法做到。
感谢发布此帖！
2 个赞
能否更具体地说明是指哪些确切的站点设置？
对所有站点设置提供无限制的只读访问权限似乎有点过于粗暴，而且会包含一些非常敏感的设置，例如 SaaS 密钥。
你可以开发一个插件，允许特定用户组对指定的一组站点设置进行只读访问吗？
那将是一个相对较小的插件。
1 个赞
philh
4
你是在问我还是 @jenmck？
目前非管理员用户无法访问，这迫使我不得不采用常规方式，因此我提出了这个请求。
philh
6
目标是完成集成工作，访问并设置所需的配置，而不使用管理员用户使用的全局范围密钥，也不使用管理员用户使用的细粒度范围密钥。
如果我仍然必须将其绑定到管理员用户，那么细粒度范围密钥在限制访问方面帮助不大。希望这能有所帮助。
你建议使用插件是个好主意，但是我不希望当前的功能集包含一个插件。我不希望 Astro 用户为了与 Discourse 连接而必须安装插件。
因此，如果你正在构建所有这些功能，那么创建一个小型插件，在自定义路由上以只读方式提供某些设置，又有什么大不了的？
能换个说法吗？