mattdm
2021 年1 月 11 日 20:57
1
I would prefer to not give a global API key to the wordpress plugin. I don’t want a compromise in the wordpress site to result in user accounts deleted (or edited, or logged out). However, limiting the scopes by guesswork seems to give weird results (like it can’t load subcategories).
What scopes does this actually need to work?
4 个赞
Falco
2021 年1 月 11 日 22:24
2
With the Wordpress pre-dating the Admin API scopes by several years I doubt it can work with it.
It’s an interesting feature request.
mattdm
2021 年1 月 11 日 22:37
3
I would really appreciate it. The global API key can do a lot of things, and we’re using our Discourse instance for more than just the blog comments, so it’d be nice to keep it scoped to just what it needs.
mattdm
2021 年1 月 11 日 23:29
4
Is such a feature request better in this category, or in features?
angus
2021 年1 月 12 日 07:36
5
I’ve been thinking the same thing! (I currently maintain the plugin). This is the right category to raise it.
I’ll discuss it with @simon and get back to you.
3 个赞
mattdm
2021 年12 月 11 日 17:47
6
@angus 这有进展吗？我们想在其中一个 WordPress 网站上使用此功能，该网站的用户群管理员权限控制不那么严格，我不想这成为在我们的 Discourse 网站上获得完全管理员权限的升级。
angus
2021 年12 月 14 日 05:55
7
马特，谢谢你对此事的跟进。我将在本周末给你一个完整的回复。
1 个赞
angus
2021 年12 月 20 日 02:15
8
@mattdm 关于此事的最新情况。我正在准备更改，以允许您生成具有特定于您正在使用的 WP Discourse 插件功能集的范围的 API 密钥。
这将需要对 Discourse 核心进行更改，因此需要获得批准。本周我将提交一个 PR，并随时向您通报最新情况。
2 个赞
angus
2021 年12 月 20 日 09:50
9
@mattdm 更新：有两个草稿中的 PR 旨在解决此问题。如前所述，该方法需要先获得批准。有关 discourse/discourse PR 的更详细说明。
main ← angusmcleod:fix_wordpress_scopes
opened 09:46AM - 20 Dec 21 UTC
I'm looking to add granular API key usage for the WP Discourse plugin. This invo… lves:
- Updating the "wordpress" default mappings to reflect the actions being used by the plugin, grouped by the feature-set they relate to (note that the existing "wordpress" action in the "topic" resource only relates to comment retrieval in the plugin, and is somewhat confusing in its current state).
- Adding a ``session/scopes`` endpoint, which returns the scopes associated with the api key in the request.
This is the companion PR on the plugin, which will provide further context to this: https://github.com/discourse/wp-discourse/pull/431. See in particular [``validate_scopes``](https://github.com/discourse/wp-discourse/pull/431/files#diff-5fd9ce264afeb5f617119db36e34a2e5a33f605527ac6fa9ee761b8123f1a17eR185).
If this approach is acceptable, I'll do some more testing before moving this out of draft. Below are some Q/A explaining my thinking behind this.
### Why does the wordpress plugin need granular scopes?
Currently the plugin requires the use of a global key, but only uses a subset of the actions, creating more risk than necessary. [See for example](https://meta.discourse.org/t/what-scopes-exactly-does-the-wordpress-api-key-need/175812).
### Why group the scopes by feature set?
This is how people use the plugin. Some use only SSO, some only publishing, some without comments etc. If a user is not using SSO they should be able to use a key that doesn't include the ``admin/user`` actions SSO requires.
Currently the "publishing" feature set cannot be totally disabled in the plugin (hence the "(required)" in the action description), however the ability to disable it (and just use SSO) may be added.
### Why add a ``session/scopes`` endpoint?
The WP Discourse plugin currently sends a request to ``/users/:username`` to test its connection to Discourse. This may be successful even if the allowed scopes are insufficient for how the plugin is configured.
A scopes endpoint tells the API consumer both whether the connection is successful and what scopes their key has. There's similar implementations in other APIs, e.g [Sendgrid](https://docs.sendgrid.com/api-reference/api-key-permissions/retrieve-a-list-of-scopes-for-which-this-user-has-access).
### Why add the ``scopes`` endpoint to the session controller?
The endpoint could go in a few different places. I figured it belonged there as essentially you're asking about the scopes in the session created when the api-authenticated request is made.
### Why not use a ``tokeninfo`` endpoint?
``tokeninfo`` endpoints are part of the OAuth 2.0 spec, which is not what we're dealing with here. Using it may be confusing.
main ← angusmcleod:granular_api_key_support
opened 09:16AM - 20 Dec 21 UTC
- Wordpress 6.0 support
- Granular API Key support (backwards compatible)
- Di… scourseConnect copy fix
- Add wpdc_publish_body filter
2 个赞
mattdm
2022 年4 月 8 日 18:35
10
这似乎停滞了。我想将此插件用于 Fedora Magazine，该杂志的设计本身就具有相当开放的访问权限——甚至比我们目前正在使用的 Fedora Community Blog 还要开放。您有任何消息吗？
angus
2022 年4 月 9 日 10:03
11
感谢您的及时提醒@mattdm，而且时机正好，因为我已经把这件事安排在下周重新处理了，现在关于 Discourse PR 已经有一些进展了。我将在下周向您汇报。
1 个赞
angus
2022 年4 月 18 日 13:07
12
请注意，Discourse 部分已提交审核（即已移出草稿）。
main ← angusmcleod:fix_wordpress_scopes
opened 09:46AM - 20 Dec 21 UTC
I'm looking to add granular API key usage for the WP Discourse plugin. This invo… lves:
- Updating the "wordpress" default mappings to reflect the actions being used by the plugin, grouped by the feature-set they relate to (note that the existing "wordpress" action in the "topic" resource only relates to comment retrieval in the plugin, and is somewhat confusing in its current state).
- Adding a ``session/scopes`` endpoint, which returns the scopes associated with the api key in the request.
This is the companion PR on the plugin, which will provide further context to this: https://github.com/discourse/wp-discourse/pull/431. See in particular [``validate_scopes``](https://github.com/discourse/wp-discourse/pull/431/files#diff-5fd9ce264afeb5f617119db36e34a2e5a33f605527ac6fa9ee761b8123f1a17eR185).
If this approach is acceptable, I'll do some more testing before moving this out of draft. Below are some Q/A explaining my thinking behind this.
### Why does the wordpress plugin need granular scopes?
Currently the plugin requires the use of a global key, but only uses a subset of the actions, creating more risk than necessary. [See for example](https://meta.discourse.org/t/what-scopes-exactly-does-the-wordpress-api-key-need/175812).
### Why group the scopes by feature set?
This is how people use the plugin. Some use only SSO, some only publishing, some without comments etc. If a user is not using SSO they should be able to use a key that doesn't include the ``admin/user`` actions SSO requires.
Currently the "publishing" feature set cannot be totally disabled in the plugin (hence the "(required)" in the action description), however the ability to disable it (and just use SSO) may be added.
### Why add a ``session/scopes`` endpoint?
The WP Discourse plugin currently sends a request to ``/users/:username`` to test its connection to Discourse. This may be successful even if the allowed scopes are insufficient for how the plugin is configured.
A scopes endpoint tells the API consumer both whether the connection is successful and what scopes their key has. There's similar implementations in other APIs, e.g [Sendgrid](https://docs.sendgrid.com/api-reference/api-key-permissions/retrieve-a-list-of-scopes-for-which-this-user-has-access).
### Why add the ``scopes`` endpoint to the session controller?
The endpoint could go in a few different places. I figured it belonged there as essentially you're asking about the scopes in the session created when the api-authenticated request is made.
### Why not use a ``tokeninfo`` endpoint?
``tokeninfo`` endpoints are part of the OAuth 2.0 spec, which is not what we're dealing with here. Using it may be confusing.
一旦该部分合并，WP Discourse 部分便可以合并和发布。
2 个赞
angus
2022 年5 月 24 日 16:34
13
@mattdm WP Discourse 2.4.3 现在已发布了细粒度范围
编辑 指南在这里！
6 个赞
system
2022 年6 月 23 日 16:35
14
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
。如果您使用的是最新版本的 Discourse 和最新版本的插件，您将能够使用它们。本周晚些时候，我将发布一篇关于如何使用它们的完整指南。