
언어 🇰🇷 한국어
배경
구현
접근 제어란 무엇인가? 
With FastComments SSO Access Control, sometimes referred to as RBAC, users can be restricted to only access certain pages, or comment threads. Additionally,
사용자는 동일한 그룹에 있는 사용자만 @mention할 수 있습니다.
자세히
우리는 Users와 선택적으로 Pages를 그룹에 배치할 수 있습니다.
Users가 그룹에 배치되고 Limit Comments by SSO User Groups가 위젯 설정에서 활성화되면, 그런 경우 사용자들은
동일한 그룹에 속한 사용자들의 댓글만 보게 되며 동일한 그룹의 사용자들만 @mention할 수 있습니다.
또한, Pages를 그룹에 배치할 수 있으며, 그 경우 사용자는 접근 권한이 있는 페이지의 댓글만 볼 수 있습니다.
이를 "User-Level" 그룹과 "Page-Level" 그룹으로 구분합니다.
그렇다면 어느 것이 적합할까요?
User-Level 그룹을 사용할 경우...
- 같은
urlId값(페이지 URL 또는 기사 ID)을 사용하되, 그룹별로 댓글을 제한하려는 경우. - 예를 들어, "New User"와 "Veteran User" 그룹을 만들고 동일한 페이지에서 서로의 댓글을 절대 보지 못하게 하려는 경우.
Page-Level 그룹을 사용할 경우...
- 그룹마다 특정 페이지가 있는 경우.
- 예를 들어, "Public Pages" 그룹에 속한 사용자는 "Top Secret" 기사들을 절대 볼 수 없어야 합니다.
작동 방식 
FastComments 액세스 제어는 원하는 그룹에 Pages 및 Users를 할당하는 방식으로 작동합니다.
그룹은 단순히 문자열 식별자이며, 예: GREEN 또는 abc-123.
Users와 Pages는 하나의 그룹에만 제한되지 않습니다. 각각 100 및 1000개의 그룹으로 제한됩니다.
권한이 없는 페이지에 접근
사용자가 접근 권한이 없는 페이지에 접근하려고 하면, 아래와 같은 오류 메시지가 표시됩니다:
메시지 텍스트는 사용자 지정할 수 있습니다.
명세 
여러 사용자가 상호작용하는 방식을 정의하고 이를 테스트하는 것은 복잡합니다. 다음은 접근 제어에 대해 우리가 따르는 규격이며, 구현을 테스트하는 데 사용할 수 있습니다:
그룹 ID가 null인 페이지, 그룹 ID가 null인 사용자 - 접근 가능해야 합니다.
그룹 ID가 null인 페이지, 그룹 ID가 있는 사용자 - 접근 가능해야 합니다.
그룹 ID가 있는 페이지, 그룹 ID가 null인 사용자 - 접근 가능해야 합니다.
그룹 ID가 있는 페이지, 그룹 ID가 빈 리스트인 사용자 - 접근할 수 없어야 합니다.
그룹 ID가 있는 페이지, 그룹 ID가 있는 사용자 - 교집합이 존재함 - 접근 가능해야 합니다.
그룹 ID가 있는 페이지, 그룹 ID가 있는 사용자 - 교집합이 없음 - 접근할 수 없어야 합니다.
그룹 ID가 빈 리스트인 페이지(아무도 접근 불가), 그룹 ID가 null인 사용자 - 접근할 수 없어야 합니다.
SSO 사용자 A = 그룹 ID 미정의 (null = 전체 접근).
SSO 사용자 B = 그룹 ID 미정의 (null = 전체 접근).
A는 @B를 언급할 수 있습니다.
SSO 사용자 A = 그룹 ID 미정의 (null = 전체 접근).
SSO 사용자 B = 그룹 ID 정의됨.
A는 @B를 언급할 수 있습니다.
SSO 사용자 A = 그룹 ID 정의됨.
SSO 사용자 B = 그룹 ID 미정의 (null = 전체 접근).
A는 @B를 언급할 수 있습니다.
SSO 사용자 A = 그룹 ID = [a].
SSO 사용자 B = 그룹 ID = [b].
A는 @B를 언급할 수 없습니다.
SSO 사용자 A = 그룹 ID = [a].
SSO 사용자 B = 그룹 ID = [a, b].
A는 @B를 언급할 수 있습니다.
구현 
다른 그룹의 사용자 멘션하기
만약 두 사용자가 서로 다른 그룹 집합에 속하고 교집합이 없다면, 서로를 @mention할 수 없습니다.
사용자가 수동으로 @mention을 입력하고 댓글을 제출하면, 그것은 일반 텍스트로 남습니다. 다른 사용자는 태그되지 않습니다.
그룹 유지 관리
Groups는 각각 Pages 및 SSOUsers API 리소스를 사용하여 정의됩니다.
Pages API는 페이지에 접근할 수 있는 그룹 집합을 정의하도록 호출할 수 있습니다. 기본적으로 모든 그룹과 그룹에 속하지 않은 사용자들도 접근할 수 있습니다.
유사하게, SSOUsers API는 각 사용자와 연관된 그룹을 정의하도록 호출할 수 있습니다.
두 리소스 모두 그룹을 언제 설정하거나 업데이트할지에 대한 제한은 없습니다.
만약 사용자가 서로를 @mention하는 것을 제한하는 것만 원한다면, Pages를 고려할 필요는 없습니다.
참고!
SSO 사용자 그룹을 정의하고 업데이트하는 데 API를 사용할 필요는 없으며, 대신 댓글 위젯에 전달되는 SSO 페이로드에 그룹 ID를 정의하여 자동으로 업데이트할 수 있습니다. 그러나 그룹 목록이 많을 경우 사용자가 매 페이지 로드마다 이 페이로드를 제출해야 하므로 권장되지 않습니다.
예제 API 호출 
여기서는 FastComments API를 호출하여 액세스 제어를 설정하는 과정을 안내합니다.
시작하기 전에, Group 구조를 명시적으로 생성할 필요가 없다는 점을 참고하세요. 그룹은 단순히 Users와 Pages에 추가되는 식별자입니다. 사용자나 페이지에 그룹을 추가하면 해당 그룹이 자동으로 "생성"됩니다.
먼저, 두 명의 사용자인 User A와 User B를 생성해 보겠습니다. 이들은 Group X에 속하도록 시작하겠습니다:


이제 Page를 하나 생성해 보겠습니다. 이를 Confidential Page라고 부르겠습니다. 현재 이 사용자들은 해당 페이지에 접근할 수 없습니다. 이 페이지는 CONFIDENTIAL 그룹에 속하기 때문입니다:

사용자 A와 B는 현재 새 페이지에 접근할 수 없습니다. 그러나 이들은 동일한 그룹인 GROUP-X에 속해 있으므로 서로 @mention할 수 있습니다.
이제 User B를 업데이트하여 해당 페이지에 접근할 수 있도록 해보겠습니다:

User B는 이제 두 그룹 모두에 속하게 되었습니다. 사용자들은 여전히 서로 @mention할 수 있지만, 기밀 페이지를 볼 수 있는 사용자는 User B뿐입니다.
이제 User B가 기밀 페이지만 볼 수 있도록 만들어 보겠습니다:

이제 User B는 기밀 페이지를 볼 수 있지만, 두 사용자는 서로 다른 그룹에 속해 있으므로 서로 @mention할 수 없습니다.
그러나 액세스 제어에 포함되지 않은 사용자는 누구나 페이지에 접근할 수 있습니다. 이를 방지하려면 SSO 사용자의 groupIds가 null로 설정되지 않았는지 확인하세요. 예를 들어, 모든 것에 접근할 수 있는 User C를 생성해 보겠습니다:

groupIds를 null로 설정하면 해당 사용자는 액세스 제어의 제한을 받지 않는다고 지정하는 것입니다.
이제 모든 사용자가 접근할 수 있는 페이지를 하나 만들어 보겠습니다:

accessibleByGroupIds를 null로 설정하면 이 Page는 액세스 제어로 관리되지 않으며, 두 사용자 모두 접근할 수 있습니다.
이로써 액세스 제어에 대한 API 워크스루를 완료했습니다.