아마도 우리가 같은 것을 구축하고 있는 것 같습니다 
다만 제 것은 부분적으로만 headless입니다.
없을 것 같고, 의도적으로 그렇게 설계된 것 같습니다.
저도 같은 것에 대해 고민해 왔지만, 제 경우에는 괜찮을 것 같습니다. 저는 Discourse를 숨기려는 것이 아니기 때문입니다.
User API 키와 관리자용 All User API 키의 차이 중 기억해 둘 점 하나는 기본적으로 서로 다른 속도 제한(rate limit)이 적용된다는 것입니다: Available settings for global rate limits and throttling.
사용자 API 속도 제한:
DISCOURSE_MAX_USER_API_REQS_PER_MINUTE : 기본값 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY : 기본값 2880
관리자 API 속도 제한:
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE : 60
애플리케이션이 자체 호스팅(self-hosted)된 Discourse 사이트에 연결되는 경우, 관리자 API 속도 제한을 오버라이드할 수 있을 가능성이 높습니다. 애플리케이션이 호스팅된 Discourse 인스턴스에 연결되는 경우, 사용자 API 속도 제한이 훨씬 더 유연합니다. 관리자 API 속도 제한을 사용하면 모든 요청을 속도 제한 큐에 넣어야 합니다.
수정: 키 생성에 User API Keys Specification을 사용하는 대신, 사용자 API 키 생성에 관리자 API 키를 사용할 수 있습니다. 이렇게 하면 사용자가 앱을 승인해야 하는 문제를 우회할 수 있습니다.
아래에 게시된 키는 제 로컬호스트(localhost) 도메인을 위한 것이므로 게시해도 위험이 없습니다.
미언코딩된 키 파라미터: {key:description:sally} {key:username:sally} {key:scopes:[scope_id:topics:write]} {key:scopes:[key:write]} {key:scopes:[name:write]} {key:scopes:[params:[topic_id]]} {key:scopes:[urls:[/posts (POST)]]} {key:scopes:[selected:true]}
❯ curl -X POST "http://localhost:4200/admin/api/keys" \
-H "Api-Key: $api_key" \
-H "Api-Username: system" \
-H "Content-Type: application/json" \
-d $json
{"key":{"id":29,"key":"f5c6307b51dd2882bde525dc9775fe7504b55c93fa40177b650f9e6b77a9d25b","truncated_key":"f5c6","description":"sally","last_used_at":null,"created_at":"2024-06-02T00:44:19.944Z","updated_at":"2024-06-02T00:44:19.944Z","revoked_at":null,"user":{"id":3,"username":"sally","avatar_template":"/user_avatar/127.0.0.1/sally/{size}/58_2.png"},"api_key_scopes":[{"resource":"topics","action":"write","parameters":["topic_id"],"urls":["/posts (POST)"],"allowed_parameters":{},"key":"write"}]}}
어떤 경우든, 결국 어떻게든 관리되어야 하는 API 키가 남게 됩니다. 암호화되어 데이터베이스에 저장될 것이라고 가정합니다.