mattdm
January 11, 2021, 8:57pm
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 Likes
Falco
January 11, 2021, 10:24pm
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
January 11, 2021, 10:37pm
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
January 11, 2021, 11:29pm
4
Is such a feature request better in this category, or in features?
angus
January 12, 2021, 7:36am
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 Likes
mattdm
December 11, 2021, 5:47pm
6
@angus Did this go anywhere? We’d like to use this on one of our wordpress sites where we have a less-than-tightly-controlled set of users with admin access, and I don’t want that to be an escalation into full admin access on our Discourse site.
angus
December 14, 2021, 5:55am
7
Hey Matt, thanks for the bump on this. I’ll give you a full response by the end of the week.
1 Like
angus
December 20, 2021, 2:15am
8
@mattdm An update on this. I’m preparing changes that will allow you to generate an API key with scopes specific to the feature-set of the WP Discourse plugin you’re using.
This will require changes to core Discourse, so it is subject to approval. Will keep you up to date this week as I make a PR.
2 Likes
angus
December 20, 2021, 9:50am
9
@mattdm Update: there are two PRs in draft that seek to address this. As mentioned the approach will needs to be approved first. More explanatory notes on the discourse/discourse PR.
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.
discourse:main ← angusmcleod:granular_api_key_support
opened 09:16AM - 20 Dec 21 UTC
Adds granular api key support. In draft as it relies on: https://github.com/disc… ourse/discourse/pull/15366
2 Likes
mattdm
April 8, 2022, 6:35pm
10
This looks like it has stalled out. I’d like to use this plugin for Fedora Magazine, which has a pretty open access policy by design — even more than the Fedora Community Blog which we’re using it with currently. Any news, by any chance?
angus
April 9, 2022, 10:03am
11
Thanks for the prompt @mattdm , and good timing as I have it in my calendar to pick this up again next week now there’s been some movement on the Discourse PR. Will give you an update on this next week.
1 Like
angus
April 18, 2022, 1:07pm
12
Just a note that the Discourse piece of this has been submitted for review (i.e. moved out of draft).
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.
Once that’s merged, the WP Discourse piece can be merged and released.
2 Likes
angus
May 24, 2022, 4:34pm
13
@mattdm Granular scopes are now released in WP Discourse 2.4.3
edit Here’s the guide!
6 Likes
system
June 23, 2022, 4:35pm
14
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
. If you’re on the latest Discourse and the latest version of the plugin you’ll be able to use them. I’ll be publishing a full guide on how to use them later in the week.