Authoring Limit 사이트 설정에 대한 API 액세스 확인

개발
1

API를 통해 동반 주제(companion topics)를 게시하고 Discourse에 동기화하는 통합 기능을 개발 중입니다. 설정 진단을 위해 포럼의 현재 작성 제한(authoring limits)을 읽어서, 주제 생성 또는 업데이트를 시도하기 전에 통합 기능이 콘텐츠를 사전 검사(preflight)할 수 있도록 하려고 합니다.

접근을 확인하려는 설정은 다음과 같습니다:

min_topic_title_length
max_topic_title_length
min_first_post_length
min_post_length
max_post_length
max_tags_per_topic
max_tag_length
tagging_enabled
create_tag_allowed_groups
tag_topic_allowed_groups

먼저 /site.json을 확인했는데, 이는 공개된 기능 힌트에 유용하게 접근할 수 있지만, 이러한 구체적인 작성 제한 설정은 노출하지 않는 것으로 보입니다.

비관리자 봇 사용자의 API 키를 사용할 때, 다음 요청은 404를 반환했습니다:

/site_settings.json
/admin/site_settings.json
/admin/site_settings

봇 사용자를 관리자로 만든 후, 다음 요청이 성공했습니다:

/admin/site_settings.json
/admin/site_settings

사용된 헤더:

Accept: application/json
Api-Key: ...
Api-Username: discussbridge-bot
X-Requested-With: XMLHttpRequest

/site_settings.json은 여전히 404를 반환했습니다.

질문 사항:

  1. /admin/site_settings.json이 현재 사이트 설정을 읽기 위한 예상된 API 경로인가요?
  2. 관리자 사용자 권한이 필요한가요, 아니면 이를 위한 지원되는 읽기 전용/세분화된 API 스코프가 있나요?
  3. /site_settings.json은 비활성화(deprecated)되었거나, 플러그인에 의존하거나, 존재하지 않는 것이 정상인가요?
  4. 통합 기능의 경우, 설정을 읽기 위해 관리자 권한이 있는 진단/설정용 키를 사용하고, 일반적인 주제/게시물 동기화 작업에는 권한이 적은 게시용 키를 사용하는 것이 권장되는 패턴인가요?

목표는 API를 통해 설정을 변경하는 것이 아니라, 설정 진단 중에 설정을 읽는 것입니다. 이를 통해 통합 기능은…

2

  1. /admin/site_settings.json입니다.

  2. client: true가 설정된 항목을 제외하고는 관리자가 되어야 합니다. 해당 항목은 /site/settings.json에서 찾을 수 있습니다.

마지막 두 항목을 제외한 필요한 모든 설정은 /site/settings.json에서 찾을 수 있습니다.

하지만 허용된 그룹의 경우 메커니즘이 다릅니다. 특정 사용자로 /site.json을 요청하면 can_tag_topics와 can_create_tags를 확인할 수 있습니다.

  1. AFAIK(본인의 지식 범위 내에서) /site_settings.json은 존재한 적이 없습니다.

  2. 특정 사용 사례의 경우, 일반 사용자 계정과 #2의 패턴을 사용하면 충분할 것이라고 생각합니다.

3

Thanks @RGJ, this was exactly the missing distinction.

I tested the paths against my forum and can confirm:

/site/settings.json

/site.json

work with my current global/admin bot key.

/site/settings.json exposes the numeric authoring limits I need, including:

min_topic_title_length
max_topic_title_length
min_first_post_length
min_post_length
max_post_length
max_tags_per_topic
max_tag_length
tagging_enabled

And /site.json, when requested as the bot user, exposes:

can_tag_topics
can_create_tag

That seems like the right pattern for setup diagnostics.

One follow-up: I also tested a granular API key scoped for topic/post/category/tag publishing work:

categories:list
categories:show
posts:edit
posts:list
search:show
tags:list
topics:write
topics:update
topics:read
topics:status

With that granular key:

/t/{topic_id}.json works
/tags.json          works
/categories.json    works

but:

/site/settings.json  403
/site.json           403

I don’t see an obvious granular scope in the admin UI that allows access to those two site-level endpoints.

Am I missing a granular scope or allowed URL configuration for /site/settings.json and /site.json?

Because the keys are for an admin bot user, each key is admin-capable at the user level. The granular key only restricts which API endpoints it may call.

If not, my practical setup during testing appears to be:

  1. a current global publishing key
  2. a global diagnostics key for setup checks that read site settings
  3. a granular publishing key candidate for normal topic/post/tag sync

If the granular publishing key proves sufficient for normal sync, the original global publishing key could be retired, leaving:

  1. granular publishing key for runtime sync
  2. global/admin-capable diagnostics key for setup checks

But that depends on whether the granular key can cover all normal publishing operations, and whether /site/settings.json / /site.json need to remain on the diagnostics side.

4

제 이해로는 이것이 Discourse의 예상된 동작입니다. 관리자가 아닌 사용자가 /site/settings.json과 /site.json을 볼 수 있고 사용할 수 있기를 더 선호합니다.

이 사안이 https://meta.discourse.org/c/contribute/feature/2로 넘어가는 것 같습니다.

참고로, Astro Discourse 통합은 순조롭게 진행되고 있으며 알파 릴리스를 앞두고 있습니다.

5