mattdm
1월 11, 2021, 8:57오후
1
WordPress 플러그인에 전역 API 키를 부여하는 것을 피하고 싶습니다. WordPress 사이트가 침해받았을 때 사용자 계정이 삭제되거나(또는 수정되거나, 로그아웃되거나) 하는 일이 일어나길 원하지 않습니다. 하지만 추측을 기반으로 스코프를 제한하면 이상한 결과가 나타나는 것 같습니다(예: 하위 카테고리를 로드하지 못하는 경우).
이것이 정상적으로 작동하려면 실제로 어떤 스코프가 필요한가요?
Falco
1월 11, 2021, 10:24오후
2
WordPress가 Admin API 스코프보다 몇 년 앞서 등장했기 때문에, 두 가지가 함께 작동할 수 있을지는 의문입니다.
흥미로운 기능 요청입니다.
mattdm
1월 11, 2021, 10:37오후
3
정말 감사하겠습니다. 전역 API 키는 많은 작업을 수행할 수 있고, 우리는 블로그 댓글 외에도 이 Discourse 인스턴스를 여러 용도로 사용 중이므로, 필요한 범위에만 권한이 제한되도록 설정하는 것이 좋습니다.
mattdm
1월 11, 2021, 11:29오후
4
Falco:
흥미로운 기능 요청이네요.
이런 기능 요청은 이 카테고리에 올리는 게 좋을까요, 아니면 features 카테고리에 올리는 게 좋을까요?
angus
1월 12, 2021, 7:36오전
5
나도 같은 생각을 하고 있었어요! (현재 이 플러그인을 유지 관리하고 있습니다). 이 카테고리가 이 문제를 제기하기 위한 적절한 곳이에요.
@simon과 논의해서 다시 알려드릴게요.
mattdm
12월 11, 2021, 5:47오후
6
@angus 이 건에 진전이 있었나요? 관리자 권한이 있는 사용자 집단의 관리가 다소 느슨한 우리 워드프레스 사이트 중 하나에서 이 기능을 사용하고 싶은데, 그렇게 하면 디스코urs 사이트에서 전체 관리자 권한으로까지 권한이 상승하는 일이 일어나는 건 원치 않습니다.
angus
12월 14, 2021, 5:55오전
7
매트, 이 게시물 올려줘서 고마워. 이번 주 안에 자세한 답변을 보내줄게.
angus
12월 20, 2021, 2:15오전
8
@mattdm 이 문제에 대한 업데이트입니다. 사용 중인 WP Discourse 플러그인의 기능 세트에 특화된 스코프를 지정하여 API 키를 생성할 수 있도록 변경 사항을 준비하고 있습니다.
이 작업에는 코어 Discourse의 변경 사항이 필요하므로 승인 여부에 따라 달라집니다. PR을 올리면서 이번 주 내로 진행 상황을 공유해 드리겠습니다.
angus
12월 20, 2021, 9:50오전
9
@mattdm 업데이트: 이 문제를 해결하기 위한 초안 상태의 PR이 두 개 있습니다. 언급했듯이 접근 방식은 먼저 승인되어야 합니다. discourse/discourse PR에 대한 추가 설명 노트가 있습니다.
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
4월 8, 2022, 6:35오후
10
이것은 멈춘 것 같습니다. 저는 이 플러그인을 Fedora Magazine에서 사용하고 싶습니다. Fedora Magazine는 기본적으로 상당히 개방적인 접근 정책을 가지고 있으며, 현재 우리가 사용하고 있는 Fedora Community Blog보다도 더 그렇습니다. 혹시 어떤 소식이 있을까요?
angus
4월 9, 2022, 10:03오전
11
@mattdm , 빠른 답변 감사합니다. 마침 Discourse PR에 움직임이 있어서 다음 주에 다시 이 일을 진행할 예정으로 캘린더에 잡아둔 상태입니다. 다음 주에 이 건에 대한 업데이트를 드리겠습니다.
angus
4월 18, 2022, 1:07오후
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.
해당 PR이 병합되면, WP Discourse 부분도 병합 및 릴리스할 수 있습니다.
angus
5월 24, 2022, 4:34오후
13
@mattdm Granular scopes가 WP Discourse 2.4.3에 출시되었습니다
수정 가이드가 공개되었습니다!
. 최신 버전의 Discourse와 플러그인을 사용 중이라면 이를 활용할 수 있습니다. 이번 주 후반에 Granular scopes 사용법에 대한 전체 가이드를 게시할 예정입니다.