How to define custom permissions for staff, admins, moderators

제품 지원
21

오래된 글이지만, 왜 테마를 GitHub 저장소로 설정하지 않나요? 디자인 및 UX 팀이 GitHub에 접근하여 테마를 업데이트할 수 있도록 권한을 부여하면 됩니다.

Discourse에서는 이제 테마를 재빌드 시 자동으로 업데이트하도록 설정할 수 있습니다.

이렇게 하면 관리자는 재빌드만 하면 디자인 및 UX 팀이 만든 변경 사항을 가져올 수 있고, 디자인 및 UX 팀은 관리자 권한이 전혀 필요 없습니다.

22

간단히 말씀드리겠습니다:

액세스 제어 관련 코딩 시, 일반적으로 이러한 RBAC 체크는 서버 측에서 수행해야 합니다.

클라이언트 측 JavaScript에 있는 RBAC 코드는 클라이언트에 의해 조작될 수 있습니다.

즉, 스태프, 관리자, 모더레이터의 핵심 RBAC 권한을 정의할 때, (일반적으로) JavaScript가 아닌 Rails에서 이를 수행해야 합니다.

참고로, Discourse도 현재 RBAC를 이 방식으로 처리하고 있습니다. Discourse가 "guardian"이라고 부르는, class Guardian이라는 Ruby 클래스를 사용하는데, 해당 코드는 여기에서 확인할 수 있습니다:

개발자가 Discourse API를 호출하여 JavaScript 코드에 RBAC 체크를 추가하려 할 경우, 브라우저에서 실행되는 코드는 조작될 수 있으므로 이 코드가 손상될 수 있다는 점을 명심해야 합니다.

제 추천 사항은 모든 핵심 RBAC 코드가 서버 측에서 수행되도록 하고, 클라이언트 측 JavaScript로 이를 단축하지 않는 것입니다.

23

Discourse 2.5 이상에서는 신뢰 수준 4와 카테고리 관리자도 있습니다.

24

저도 비슷한 사용 사례가 있습니다. 저는 작은 비영리 커뮤니티를 운영하고 있는데, 그중 한 사용자가 테마와 디자인을 유지 관리하고 있습니다.

제자와 공동 소유자 외에 다른 사용자에게 개인 사용자 데이터(이메일 주소 등)에 대한 접근 권한을 부여하고 싶지 않지만, 현재 4명의 관리자를 두고 있습니다.

디자이너가 업무를 수행할 수 있도록 콘텐츠가 없는 복사 사이트를 만들어在那里를 관리자로 설정하고, 테마와 구성 요소를 수동으로 복사하고 있습니다. 그러나 일부 변경 사항은 콘텐츠가 있어야만 검증할 수 있으므로 이 방법은 바람직하지 않습니다.

25

스테이징/테스트 사이트에 콘텐츠를 추가해 보는 건 어떨까요? 일반적으로 그렇게 권장됩니다.

26

그래서 개발자가 스테이징 사이트에서 개발을 진행하도록 하고, 테마를 GitHub에 푸시하도록 합니다. 하지만 업그레이드는 여전히 직접 수행해야 합니다. API를 통해 업그레이드를 수행하고, 개발자가 이를 트리거할 수 있도록某种 방법을 고안해 볼 수 있습니다.

이를 도울 수 있는 도구를 개발 중입니다.

27

저희도 정확히 같은 문제를 겪고 있습니다. 혹시 이 문제를 해결하신 분이 계신가요?

28

이 상황에서 유용할지 모르겠지만, 단순히 콘텐츠가 필요하다면 populate rake 작업을 사용할 수 있습니다:

29

감사합니다. 하지만 안타깝게도 지금은 별로 도움이 안 됩니다.

30

디자이너가 사용자의 데이터를 볼 수 있다고 신뢰하지 않는다면, 어떤 해결책이 가능할 것 같나요?

discourse_cli를 통해 테마를 해당 서버로 푸시할 수 있도록 API 키만 제공하고, 작업이 끝나면 해당 키를 비활성화하는 방식이 어떨까요?

31

디자이너가 10만 명 사용자의 데이터에 접근할 이유는 전혀 없습니다. lol. 또한 이는 GDPR 규정에도 위배됩니다. 테마 업데이트를 위한 CLI 키만 제공하는 것은 가능한가요?

32

실례합니다! 말씀이 맞으신 것 같습니다.

이 주제가 생성되었을 때와 달리(그때 제가 이 답글을 작성했을 당시 제 뇌가 어디에 있었는지 모르겠습니다), 현재 세밀한 API 키를 사용할 수 있습니다. 테마 관리 전용으로 새로운 스코프를 추가하는 것은 그리 어렵지 않을 것입니다.

Contribute > Feature 채널에서 테마 개발자용 API 키 스코프를 요청하는 새로운 주제를 만드는 것도 좋은 방법일 수 있습니다. 꽤 좋은 아이디어라고 생각합니다.

33

아니요, 그렇지 않습니다. 해당 사이트의 규칙에 위배될 수는 있지만, 그 규칙들은 변경될 수 있고 변경되어야 합니다.

34

@AV_C 님이 이 _요구사항_에 대한 참고 자료를 게시해 주시면 좋겠습니다. 고객이 다양한 이유로 사용자 기반 및 비공개 카테고리 접근을 제한하고 싶어하는 이유를 충분히 이해합니다. Full Admin은 회원 가입 이메일에 접근할 수 있으며, 비공개 카테고리에는 고객의 사용 사례에 따라 다른 민감한 내용이 포함될 수 있습니다.

@pfaffman 님의 아이디어가 좋다고 생각합니다. 제한된 관리자 API를 통해 이러한 문제를 해결할 수 있습니다. 디자인 작업이 완료되면 필요할 때까지 키를 무효화할 수 있습니다.

이 방식은 Jay 님의 아이디어인 About 페이지에서 사용자를 관리자로 표시하지 않는 것과도 부합합니다.