mattdm
(Matthew Miller)
11.Январь.2021 20:57:39
1
Я бы предпочел не передавать глобальный ключ API плагину WordPress. Я не хочу, чтобы компрометация сайта WordPress приводила к удалению (или редактированию, или разлогиниванию) учетных записей пользователей. Однако ограничение областей доступа методом проб и ошибок дает странные результаты (например, не загружаются подкатегории).
Какие именно области доступа необходимы для работы?
Falco
(Falco)
11.Январь.2021 22:24:55
2
Учитывая, что WordPress появился за несколько лет до внедрения области применения (scopes) Admin API, сомневаюсь, что это возможно.
Это интересная просьба о добавлении новой функции.
mattdm
(Matthew Miller)
11.Январь.2021 22:37:24
3
Я был бы вам очень признателен. Глобальный API-ключ может выполнять множество задач, и мы используем наш экземпляр Discourse не только для комментариев в блоге, поэтому было бы неплохо ограничить его права только тем, что ему действительно необходимо.
mattdm
(Matthew Miller)
11.Январь.2021 23:29:27
4
Стоит ли предлагать такую функцию в этой категории или в разделе «Функции»?
angus
(Angus McLeod)
12.Январь.2021 07:36:31
5
Я об этом же думал! (Я сейчас поддерживаю этот плагин). Это правильный раздел, чтобы поднять эту тему.
Я обсудлю это с @simon и отвечу вам.
mattdm
(Matthew Miller)
11.Декабрь.2021 17:47:54
6
@angus , это привело к чему-нибудь? Мы хотели бы использовать это на одном из наших сайтов на WordPress, где у нас есть менее строго контролируемый набор пользователей с правами администратора, и я не хочу, чтобы это привело к получению ими полных прав администратора на нашем сайте Discourse.
angus
(Angus McLeod)
14.Декабрь.2021 05:55:18
7
Привет, Мэтт, спасибо, что напомнил об этом. Я дам тебе полный ответ до конца недели.
angus
(Angus McLeod)
20.Декабрь.2021 02:15:17
8
@mattdm Обновление по этому вопросу. Я готовлю изменения, которые позволят вам создавать API-ключи с правами доступа, соответствующими функциональным возможностям используемого вами плагина WP Discourse .
Это потребует изменений в ядре Discourse, поэтому они подлежат утверждению. Буду держать вас в курсе на этой неделе по мере подготовки PR.
angus
(Angus McLeod)
20.Декабрь.2021 09:50:31
9
@mattdm Обновление: есть два черновых PR, направленные на решение этой проблемы. Как уже упоминалось, сначала необходимо утвердить выбранный подход. Дополнительные пояснительные примечания по PR в репозитории discourse/discourse.
main ← angusmcleod:fix_wordpress_scopes
merged 03:15PM - 02 May 22 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
merged 04:27PM - 24 May 22 UTC
- Wordpress 6.0 support
- Granular API Key support (backwards compatible)
- Di… scourseConnect copy fix
- Add wpdc_publish_body filter
mattdm
(Matthew Miller)
08.Апрель.2022 18:35:51
10
Похоже, процесс застрял. Я хотел бы использовать этот плагин для Fedora Magazine, где политика открытого доступа по замыслу ещё более либеральная, чем у блога Fedora Community, который мы сейчас используем. Есть ли какие-нибудь новости?
angus
(Angus McLeod)
09.Апрель.2022 10:03:13
11
Спасибо за быстрый ответ, @mattdm . И очень вовремя: я уже запланировал в календаре вернуться к этому на следующей неделе, так как по PR в Discourse есть движение. Дам вам обновление по этому вопросу на следующей неделе.
angus
(Angus McLeod)
18.Апрель.2022 13:07:24
12
Напоминаю, что часть, касающаяся Discourse, была отправлена на ревью (т.е. перемещена из черновика).
main ← angusmcleod:fix_wordpress_scopes
merged 03:15PM - 02 May 22 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 .
angus
(Angus McLeod)
24.Май.2022 16:34:19
13
@mattdm Тонкие области доступа теперь доступны в WP Discourse 2.4.3 . Если вы используете последнюю версию Discourse и последнюю версию плагина, вы сможете их применять. Полное руководство по их использованию я опубликую позже на этой неделе.
редактирование Вот руководство!