권한
백오피스 접근이 역할과 조직에 의해 어떻게 제어되는지 설명합니다.
소개
CLUAR는 조직 내의 사람에게 할당된 역할(그룹)을 통해 백오피스 접근을 제어합니다. 서버의 각 REST 서비스는 접근 범주로 분류되며, 올바른 조직 내에서 올바른 역할을 가진 사람만 해당 서비스를 사용할 수 있습니다.
역할
미리 생성된 5개의 역할(user_group)이 있습니다:
| 코드 | 이름 |
|---|---|
administrator | 관리자 |
editor | 편집자 |
author | 작성자 |
contributor | 기여자 |
subscriber | 구독자 |
현재 실제로 무언가에 접근할 수 있는 역할은 관리자와 편집자뿐입니다. 이 두 역할이 접근 규칙에서 참조되는 유일한 역할입니다(아래 참고). 작성자, 기여자, 구독자는 이미 양식에서 옵션으로 존재하지만 아직 구성된 접근 권한이 없습니다. 이런 역할 중 하나를 누군가에게 할당해도 현재 백오피스에서는 아무것에도 접근할 수 없습니다.
조직
한 사람은 조직의 맥락 안에서만 역할을 가집니다. 연결은 조직 > 구성원(organization_people)에서 이루어지며, 사람 + 조직 + 역할을 연결합니다.
현재 코드가 admins인 조직이 하나만 존재하며, 모든 권한은 이 조직에서 확인됩니다. organization 엔터티는 계층 구조(parent_id, "상위" 조직)를 지원하지만, 이 계층 구조는 현재 권한 규칙에서 아직 사용되지 않습니다. 모든 확인은 admins 조직을 직접 가리킵니다.
편집 모드 최초 접근
CLUAR는 로그인할 수 있는 서로 다른 두 장소를 구분합니다:
- Netuno 백오피스(개발 환경에서는
9000포트) — Netuno 사용자(netuno_user, username/password 쌍)와 사람 및 역할을 포함한 모든 엔터티를 직접 관리하는 곳입니다. - 웹사이트 자체의 전용 영역(
/login, 개발 환경에서는3000포트) — 콘텐츠 편집자가 일상적으로 들어와 페이지 편집 모드에 접근하는 곳입니다.
전용 영역에 들어가 편집 모드를 사용하려면 로그인이 가능한 Netuno 사용자가 사람과 연결되어 있어야 하며, 그 사람은 관리자 또는 편집자 역할로 admins 조직에 연결되어 있어야 합니다(위의 조직 참고).
기본 사용자
CLUAR의 server/setup/030-people.js는 기본적으로 id: 2인 Netuno 사용자와 연결된 "admin" 사람을 이미 생성하며, server/setup/050-organization_people.js는 이 사람을 관리자 역할로 admins 조직에 연결합니다. 즉, 이 사용자는 처음부터 전체 접근 권한을 가집니다.
이 기본 사용자의 로그인 정보는 다음과 같습니다:
사용자: admin
비밀번호: admin
이 자격 증명으로 먼저 Netuno 백오피스에서 추가 단계를 거칠 필요 없이 바로 관리자로서 전용 영역(/login)에 들어갈 수 있습니다.
admin/admin은 널리 알려져 있고 예측 가능한 자격 증명입니다. 사이트를 운영 환경에 배포하기 전에 이 사용자의 비밀번호를 변경하거나(또는 새 관리자를 만들고 이 사용자를 비활성화하세요).
새 사용자 만들기
가능한 방법은 두 가지입니다:
전용 영역에서(권장): 사용자 > 사용자 생성에서 하나의 양식이 이름, 사용자 이름, 비밀번호, 이메일, 조직 및 역할을 요청하고, 한 번에 모든 것을 생성합니다. Netuno 사용자, (해당 사용자와 이미 연결된) 사람, 그리고 선택한 조직/역할에 대한 연결입니다. Netuno 백오피스를 거칠 필요가 없습니다.
Netuno 백오피스에서만: 백오피스는 모든 엔터티에 직접 접근할 수 있으므로, 그곳을 벗어나지 않고 동일한 3단계를 수동으로 수행할 수도 있습니다:
- 선택한 username/password로 Netuno 사용자(
netuno_user)를 생성합니다. - 사람을 생성하고 해당 Netuno 사용자와 연결합니다.
조직 > 구성원에서 이 사람을 관리자 또는 편집자 역할로admins조직에 연결합니다.
두 경우 모두 생성된 사람은 이미 /login에 들어가 편집 모드에 접근할 수 있습니다.
권한이 적용되는 방식
서버의 각 서비스는 server/core/_service_config.js에 정의된 다음 범주 중 하나로 분류됩니다:
| 범주 | 접근 가능 대상 | 예시 |
|---|---|---|
| 공개 | 로그인 없는 모든 사람 | 연락처, 아바타, 로그인 |
| 콘텐츠 관리 | 관리자 + 편집자 | 페이지, 버전, 컴포넌트, 사전, 액션 |
| 사이트 관리 | 관리자만 | 설정, 언어, 동기화 |
| 접근 관리 | 관리자만 | 조직, 사람, 사용자 |
이 범주 중 어디에도 나열되지 않은 서비스는 기본적으로 거부됩니다. 이는 코드의 의도적인 결정으로(파일에 명시적으로 주석 처리됨), 새 서비스 분류를 잊어버렸을 때 부주의로 자유롭게 접근되는 대신 차단되도록 하기 위한 것입니다.
dev 환경에서 _service_config.js는 어떤 검사보다도 먼저 시작 부분에서 모든 서비스를 허용합니다. 즉, 권한은 운영/스테이징 환경에서만 실제로 적용됩니다. 로컬에서 테스트할 때는 역할과 관계없이 로그인한 모든 사용자가 모든 것에 접근할 수 있습니다.
인터페이스: 메뉴도 권한으로 필터링
서버에서의 차단 외에도, 전용 영역의 사이드 메뉴(website/src/components/SideMenu)는 로그인한 사람의 역할에 따라 표시되는 항목을 필터링합니다. 사용 권한이 없는 옵션을 표시하지 않기 위해서입니다.
SideMenu의 "누가 무엇을 볼 수 있는지" 목록은 _service_config.js의 CONTENT_MANAGEMENT_PATHS, SITE_ADMIN_PATHS, ACCESS_MANAGEMENT_PATHS와 수동으로 정렬된 상태로 유지됩니다. 이들은 프런트엔드와 백엔드에 각각 하나씩 있는 별도의 목록입니다. 새 보호 서비스를 추가할 때는 두 목록을 모두 업데이트해야 합니다. 서버만 변경하면 오류가 숨겨지고(메뉴에는 실제로는 거부될 옵션이 계속 표시됨), 메뉴만 변경하면 실제로 아무것도 보호되지 않습니다.
새 서비스를 보호하는 방법
server/services/에 서비스를 평소처럼 생성합니다.- 서비스 경로(
path/method)를 누가 사용할 수 있어야 하는지에 따라server/core/_service_config.js의 올바른 목록(CONTENT_MANAGEMENT_PATHS,SITE_ADMIN_PATHS또는ACCESS_MANAGEMENT_PATHS)에 추가합니다. 공개 서비스라면PUBLIC_PATHS에 추가합니다. - 서비스에 전용 영역 메뉴의 대응 항목이 있다면, 필터가 실제 권한과 정확히 일치하도록
SideMenu도 업데이트합니다.