Discourse API 시스템 2개의 목적

Discourse API 인증 시스템 두 가지가 언제, 어떤 목적으로 작동하는지 명확히 하고 싶습니다.

(여기에서 가져옴). 제 현재 이해를 바탕으로 정리하면 다음과 같습니다:


**관리자 API**는 때로는 JSON API라고도 불리며, Discourse 포럼과 상호작용하기 위해 API 호출을 수행할 때 다음 두 가지 경우에 사용할 수 있습니다:

  1. 해당 호출에 인증이 필요하지 않은 경우, 또는
  2. 인증이 필요하지만, Discourse 포럼에 대한 직접적인 제어 권한이 있어 포럼 및/또는 별도 앱에서 API 호출을 수행하기 위해 API 키를 수동으로 생성할 수 있는 경우.

반면, **사용자 API**는 Discourse 포럼(또는 포럼들)과 상호작용하되, 해당 상호작용에 인증이 필요하고, 상호작용하려는 포럼(또는 포럼들)을 제어하지 않는 경우에 사용하도록 설계되었습니다.

다른 표현을 하자면, 관리자 API는 포럼을 제어하는 경우를 위해, 사용자 API는 포럼을 제어하지 않는 경우를 위한 것입니다.

이것이 올바른 이해인가요?

예를 들어, @david의 여기 설명에 따르면, 관리자 API는 JavaScript 클라이언트와 함께 사용하도록 의도되지 않았습니다. 하지만 제 생각에는 JavaScript 클라이언트를 사용하는 앱의 소유자가 포럼도 제어하는 한(즉, 별도 앱의 소유자와 포럼의 소유자가 동일한 경우), JavaScript 클라이언트와 함께 관리자 API를 사용하는 데 문제가 없을 것입니다. 맞나요?

그렇게 작동한다고 생각합니다. 별도 앱에서 Discourse 사이트의 관리자 API에 대한 호출을 수행하려면, 백엔드(서버 사이드)에서 그 호출을 수행할 수 있다고 믿습니다. 백엔드에서 수행하지 않고 클라이언트 사이드에서 수행하면 CORS 제한에 부딪힐 수 있습니다. 그런 경우, admin/site_settings/security/ → "cors origins"에서 별도 앱의 도메인을 화이트리스트에 추가할 수 있습니다.

아래에는 이러한 API가 어떻게 작동하는지에 대한 추가 세부 정보도 포함했습니다. 여전히 가지고 있는 다른 질문이 하나 있습니다: 관리자 API의 API 키를 설정할 때, 사용자 수준으로 "All Users"를 사용하는 것이 적절한 경우는 언제인가요?

상세 정보:

관리자 API

기본 사항

이것은 docs.discourse.org에 설명된 API입니다. 때로는 JSON API라고도 불립니다.

이 API의 엔드포인트와 상호작용함으로써, 여기에 설명된 방법을 사용하여 Discourse 사이트에서 직접 수행할 수 있는 거의 모든 작업을 수행할 수 있습니다.

일부 엔드포인트는 인증을 요구합니다. 예를 들어, 특정 그룹의 세부 정보를 가져오기 위해 API를 사용하려는 경우(엔드포인트: [your-forum]/groups/[group-name].json), 그 그룹이 멤버에게만 표시되는 경우, 해당 엔드포인트에 대한 호출을 멤버 중 한 명의 "대리"로 수행해야 합니다.

적절한 인증을 사용하여 API 호출을 하려면, [your-forum]/admin/api → New API Key에서 API 키를 생성해야 합니다. 이때 해당 키의 사용자 수준으로 "Single User"를 선택하고, 리소스(예: 그룹 정보)를 볼 권한이 있는 사용자를 선택합니다.

그 후 API 호출을 수행할 때, 헤더에 키를 Api-Key로, 사용자의 사용자명을 Api-Username으로 포함해야 합니다.

API 키를 설정할 때 "All Users"를 선택하는 옵션도 있습니다. 위의 제 질문에 따라, 이것이 언제 적절한지, 예를 들어 단일 사용자를 선택하고 그 사용자가 관리자(A)인 경우와 어떻게 다른지 확실하지 않습니다.

사용 시점

Discourse 앱 "내부"에서 관리자 API를 사용할 수 있습니다. 즉, 다음 곳에서 관리자 API와 상호작용할 수 있습니다: (i) [your-forum]/admin/customize의 각 테마에 대한 CSS/HTML 편집 대시보드에서, (ii) Discourse 사이트에 통합하는 테마에서, 그리고 (iii) Discourse 사이트에 통합하는 플러그인에서.

Discourse 포럼을 제어하여 별도 앱이 사용할 API 키를 포럼을 통해 수동으로 생성할 수 있다면, 별도 앱에서도 관리자 API를 사용할 수 있습니다.

위의 제 질문에 따라, 확인받고 싶은 이해 내용입니다.

사용자 API

이 API의 세부 사항은 여기에서 설명됩니다: User API keys specification

사용자 API가 존재하는 이유는, 관리자 API가 포럼과 별개의 어떤 사이트나 앱에서도 접근할 수 있는 일반 API로 사용하도록 의도되지 않았기 때문이라고 생각합니다.

이를 명확히 하기 위해, 별도 앱이 Discourse 포럼과 상호작용할 수 있는 두 가지 다른 시나리오가 있습니다:

시나리오 1: 직접 연결 없음: Discourse 포럼과 연결되지 않은 개발자가 포럼과 상호작용하는 앱을 생성합니다. 예를 들어, 포럼의 관리자가 아니거나 포럼 관리자와 다른 방식으로 연결되지 않은 개발자가 여러 Discourse 사이트에서 몇 가지 사실이나 정보를 가져오기 위해 앱을 만들고자 하는 경우입니다.

이 시나리오에서, Discourse 포럼 관리자는 연결되지 않은 개발자에게 API 키를 수동으로 생성하여 제공할 것입니다. 따라서 관리자 API는 적절하지 않습니다.

따라서, YouTube와 같은 많은 사이트가 제3자 개발자가 만든 앱에서 YouTube와 상호작용할 수 있도록 API를 제공하는 것처럼, Discourse 사용자 API는 제3자 앱이 포럼과 상호작용할 수 있는 방법입니다. 이때 앱(데스크톱, 모바일 폰)을 사용하는 클라이언트가 포럼에 대한 제한된 접근 권한을 부여하는 API 키를 생성합니다.

시나리오 2: 직접 연결된 앱: 포럼의 관리자(또는 관리자와 연결된 개발자)가 포럼과 상호작용하기를 원하는 별도 앱과 연결되어 있습니다.

예를 들어, 관리자가 Discourse 기능이 아닌 별도 기능이 있는 별도 앱이 있기를 원하고, 그 별도 앱의 사용자와 포럼 사용자 사이에 중복이 있기를 원할 수 있습니다. 이 경우, 관리자는 실제로 직접(포럼 관리자 대시보드를 통해 수동으로) API 키를 생성하여 별도 앱에 제공할 수 있으며, 이렇게 하면 별도 앱이 관리자 API를 활용할 수 있습니다.

애플리케이션에 API 키를 포함하여 배포하면 해커가 해당 키를 애플리케이션 바이너리 또는 와이어 프로토콜에서 쉽게 추출해 낼 수 있습니다.

사용자 API는 이러한 문제에서 면제됩니다. 사용자가 애플리케이션을 승인하면 전용 API 키가 생성됩니다.

관리자 API의 주요 사용 사례는 무엇인가요?

제 경우, 다음과 같은 목적으로 사용하고 있습니다:

  1. API 호출을 통해 포럼에 표시할 데이터를 보내어 포럼에 콘텐츠를 추가합니다. 이를 위한 대안 방법으로는 플러그인을 통해 ember/rails 코드를 추가하여 다양한 유형의 데이터를 생성하고 표시하는 것입니다. 현재로서는 API를 사용하는데, 프로그래밍 관점에서 API를 이해하고 JavaScript로 상호작용하는 것이 discourse 코드베이스를 숙달하고 ember와 rails에 능숙해지는 것보다 훨씬 이해하기 쉬우며 사용하기에 편하기 때문입니다.
  2. 제가 별도로 가지고 있는 앱이 포럼과 상호작용할 수 있도록 허용합니다.

두 경우 모두 사용자 API로는 작동하지 않습니다. 검색 및 표시해야 할 데이터가 특정 사용자에게 국한되지 않는 경우가 많기 때문입니다. 기본적으로 API 키가 프론트엔드에 노출되는 것을 원치 않는다는 점은 이해합니다. 이 문제를 해결하면서도 관리자 API를 계속 사용하기 위해, 저는 키를 백엔드에 보관하고 포럼에서 해당 백엔드로 호출을 보내고 있습니다. 따라서 포럼은 백엔드 엔드포인트 URL(이것은 문제가 되지 않음)은 노출하지만, 그곳에 보관된 API 키는 노출하지 않습니다.

사용자 API는 바로 이 용도로 설계되었습니다. 참고 구현으로 Discourse Hub의 소스 코드를 확인해 보세요.

관리자 API는 어떤 목적으로 설계되었나요?

관리자 API는 서버 간 상호작용에 사용됩니다. 예를 들어, 웹사이트의 백엔드에서 호출하는 요청 등이 해당됩니다.