권한

소개

Permissions 탭은 특정 저장소에 대해 누가 어떤 폴더를 읽거나 쓸 수 있는지 정의합니다. 권한은 그룹 또는 사용자 를 대상으로 하며, 경로 패턴 에 적용되고, 수준（write / read / none）을 가집니다. 역할은 계정이 무엇을 할 수 있는지를, 권한은 어떤 파일에 대해서인지를 정합니다.

접근과 역할

이 탭은 슈퍼 관리자（모든 저장소）와 project_admin （자신이 관리하는 저장소）가 사용할 수 있습니다. 규칙은 항상 선택된 저장소에 연결됩니다.

탭의 세 패널

Permissions 탭은 관리 패널의 PROJECT 행에 있습니다. 여기서 하는 모든 작업은 행 상단의 선택기에 표시된 저장소에만 적용됩니다. 바로 위의 SERVER 행은 반대로 서버 전체에 관한 것이며, 계정과 그룹이 그곳에 있습니다.

이 탭은 위에서 아래로 세 개의 서로 다른 패널 을 쌓아 놓습니다. 이들은 세 가지 서로 다른 질문에 답하며, 앞의 두 개를 폴더 트리와 혼동하는 것이 이 페이지에서 가장 잦은 문의 원인입니다.

패널	답하는 질문	접근할 수 있는 사람
Project Admins	이 프로젝트는 누가 관리하는가?	슈퍼 관리자만
Build Access	이 프로젝트의 빌드를 누가 다운로드할 수 있는가?	슈퍼 관리자와 project_admin
권한 트리	누가 어떤 폴더를 읽거나 쓸 수 있는가?	슈퍼 관리자와 project_admin

이 페이지의 나머지는 먼저 주 패널인 권한 트리를 설명하고, 이어서 나머지 두 개를 설명합니다.

세 가지 수준

수준	효과
write	대상 경로에서 읽기와 쓰기（체크아웃, 체크인）.
read	읽기 전용: 동기화는 가능하지만 수정은 불가.
none	접근 없음: 더 넓은 규칙이 허용하더라도 폴더를 명시적으로 숨깁니다.

접근 권한 부여

1. 올바른 프로젝트에서 Permissions 탭 열기

PROJECT 행, 행 상단의 저장소 선택기: 무엇보다 먼저 표시된 프로젝트를 확인하세요. 규칙은 그 프로젝트에만 연결됩니다.

2. 대상 선택

선택기에서 그룹 또는 사용자를 고릅니다. 목록은 Groups 와 Users 두 개의 하위 목록으로 나뉩니다. 하나의 규칙은 둘 중 하나만 대상으로 하며, 둘 다 대상으로 하지 않습니다. 대상이 선택되지 않은 동안 Apply 버튼은 비활성 상태로 유지됩니다.

3. 폴더 체크

폴더 트리 에서 해당 폴더를 체크합니다. 체크박스는 세 가지 상태（전체, 부분, 없음）이며, Filter folders... 필드는 프로젝트가 클 때 트리를 좁혀 줍니다.

4. 수준 선택 후 적용

폴더를 체크하면 곧바로 막대가 나타납니다. 선택된 폴더 수를 알려 주고 세 가지 수준（write, read, none）을 제시합니다. 하나를 고른 뒤 Apply 를 클릭합니다. 그러면 대상의 규칙이 아래 Active rules 표（Path Pattern, Permission, Priority）에 표시되며 하나씩 삭제할 수 있습니다.

사용자 이름으로 부여

"+ By username" 버튼을 사용하면 보이는 목록에 나타나지 않는 사람에게도 그 정확한 이름 을 입력하여 접근 권한을 부여할 수 있습니다. 이는 아직 어떤 권한도 갖지 않은 playtester 처럼 평소 범위 밖의 계정에 접근 권한을 부여하는 방법입니다.

이름은 정확히 일치해야 합니다（접두사 불가）. 이 필드는 식별자와 이름만 반환하며, 역할은 결코 반환하지 않습니다. 기존 계정을 탐색하는 데 사용되지 않도록 하기 위함입니다.

패턴과 우선순위

규칙은 특정 파일이 아니라 경로 패턴, 이른바 glob 을 대상으로 합니다. 이는 축약 표기로, * 는 이름 안의 임의의 문자열을, ** 는 임의의 깊이의 임의의 폴더열을 나타냅니다. 따라서 Content/Maps/** 는 Content/Maps 아래의 모든 것 (하위 폴더 포함)을 가리킵니다. 손으로 쓸 필요는 없습니다. 트리에서 폴더를 체크하면 해당 glob 이 생성됩니다.

체크한 폴더 Foo/Bar 는 패턴 Foo/Bar/** 가 됩니다（해당 폴더와 임의의 깊이에 포함된 모든 것）. 저장소 루트는 /** 가 됩니다.

각 규칙에는 폴더의 깊이와 같은 우선순위 가 자동으로 부여됩니다（세그먼트 수, 루트 = 0）. 따라서 더 구체적（더 깊은）인 규칙이 더 일반적인 규칙보다 우선합니다. 예: Content/** 에 write, Content/Secret/** 에 none 을 지정하면, Content/ 전체에서 쓰기가 가능하지만 Secret/ 만 제외됩니다.

기본 해석

명시적 규칙이 경로를 다루지 않을 때, 실효 접근은 다음 모델을 따릅니다:

• 기본적으로, 일치하는 규칙이 없으면 접근은 read（읽기）입니다.
• admin 과 lead 는 어디서나 write（역할 우회）를 가집니다.
• project_admin 은 자신이 관리하는 저장소에서 write 를 가지며, 그 외에는 특별한 권한이 없습니다.
• 그 밖에는 가장 구체적인 규칙이 적용됩니다. 해당이 없으면 기본 읽기입니다.

다시 말해: 이미 저장소에 접근할 수 있는 사람에게 폴더 읽기를 금지 하려면 아무것도 부여하지 않는 것만으로는 충분하지 않고（기본이 read이므로）, 명시적인 none 규칙이 필요합니다.

실용적인 결과이며 불필요한 작업을 덜어 줍니다: 규칙이 전혀 없는 새 프로젝트는 이미 모두에게 닫혀 있습니다. 단, admin 과 lead 역할, 그리고 그 프로젝트 자신의 project_admin 은 예외입니다. 따라서 프로젝트를 「닫기」 위해 곳곳에 none 규칙을 둘 필요가 없습니다. 열고 싶은 것만 부여하면 됩니다. none 규칙은 이미 부여한 접근의 내부 를 나누는 데 씁니다. 예를 들어 Content/ 를 가진 팀에게서 Content/Secret/ 를 숨기기 위해서입니다.

프로젝트 관리자 지정

탭 상단의 Project Admins 패널은 선택된 저장소를 누가 관리하는지 지정합니다. 이는 슈퍼 관리자 전용 입니다: 권한을 부여하는 것은 그것을 행사하는 것보다 한 단계 위이기 때문입니다.

절차는 다음 순서로 두 단계입니다:

1. Users 탭에서 역할 부여

SERVER 행, Users 탭: 그 사람에게 project_admin 역할을 부여합니다. 그 역할이 설정되기 전까지는 이 패널의 목록에 나타나지 않으며, 패널도 이렇게 알려 줍니다: 「No one to add. Give someone the Project Admin role on the Users tab first」.

2. 그 사람을 저장소에 연결

여기로 돌아와 PROJECT 행 선택기에 표시된 저장소를 확인한 다음, Project Admins 패널에서 Add 를 클릭하고 그 사람을 선택한 뒤 Grant 를 클릭합니다. 그 사람은 곧바로 패널 목록에 나타납니다.

연결 해제

행 끝의 빨간 십자 표시（Revoke）는 그 저장소를 대상 범위에서 제거합니다. 연결 없는 역할은 아무것도 주지 않습니다: 더 이상 어떤 저장소도 관리하지 않는 project_admin 은 Permissions, Rules, Webhooks, Files 그리고 사용자 관리에 대한 접근을 잃습니다. 따라서 마지막 저장소를 제거하면 권한 전체가 제거됩니다.

빌드 접근

Build Access 패널은 이 프로젝트의 게시된 빌드 를 클라이언트의 Games 페이지에서 누가 보고 다운로드할 수 있는지 결정합니다. 슈퍼 관리자 와, 자신의 저장소에 대한 project_admin 에게 열려 있습니다.

1. 추가 양식 열기

Build Access 패널에서 Add 를 클릭합니다. 입력 행이 나타나며, 먼저 대상을 지정하는 방법의 선택으로 시작합니다.

2. 대상 지정

• User: 목록에 있는 계정, 즉 이미 프로젝트에서 일하는 사람.
• Group: 그룹 전체. 학생 무리나 반복되는 테스트 팀에 편리합니다.
• By username: 계정의 정확한 이름을 입력하는 Exact username 필드. playtester 에게는 통상적인 방법입니다. 어떤 목록에도 나타나지 않기 때문입니다. 이름은 접두사 없이 정확히 일치해야 합니다.

3. 부여 또는 취소

부여하려면 Grant 를 클릭합니다. 기존 행에서는 Revoke 가 확인과 함께 접근을 제거합니다.

서버가 적용하는 규칙, 순서대로:

누가	빌드 접근
admin	모든 저장소.
project_admin	자신이 관리하는 저장소.
그 밖의 모든 역할	download_builds 능력을 가져야 하며（viewer 를 제외한 모든 역할이 가집니다）, 그리고 저장소에 접근할 수 있거나, 직접 또는 그룹을 통해 이 패널에 행이 있어야 합니다.

다시 말해: 이미 프로젝트에서 일하는 사람은 여기서 더 필요한 것이 없습니다. 이 패널은 프로젝트 외부 의 사람을 위한 것이며, viewer 는 어떤 경우에도 제외된 채로 남습니다.

권한 테스트

탭 맨 아래의 Test Permission 패널은 「이 사용자가 이 경로에 대해 어떤 실효 접근을 갖는가?」에 답합니다. 어느 규칙이 실제로 결정하는지를 아는 가장 빠른 방법입니다.

1. 사용자와 경로 선택

User 에서 계정을 고른 다음 Path 에 경로를 입력합니다. 예를 들어 /Content/Maps/Level01.umap 입니다. 둘 다 채워지기 전까지 버튼은 비활성 상태로 유지됩니다.

2. 테스트 실행 후 결과 읽기

Test 를 클릭합니다. 결과에는 실효 수준과 함께 결정을 내린 소스 와 패턴 이 표시되어, 접근이 허용되거나 거부되는 이유를 이해할 수 있습니다.

볼 권한이 없는 사용자에 대해서는, 테스트가 존재하지 않는 계정과 동일한 「찾을 수 없음」을 반환하여 계정의 존재를 드러내지 않습니다.

흔한 함정

「아무것도 부여하지 않았는데 읽을 수 있다」

이는 read 기본값 때문이며, 그 사람이 이미 접근할 수 있는 저장소 내부 에서만 작동합니다. 프로젝트에서 일하는 사람에게 폴더를 닫으려면 해당 폴더에 명시적인 none 규칙을 설정하세요.

「저장소가 그 사람의 목록에 나타나지 않는다」

그 사람이 이 저장소에 대해 none 이외의 규칙을 전혀 갖지 않는 동안은 정상입니다. read 기본값은 저장소 자체에 대한 접근을 주지 않습니다. 직접 또는 그룹 을 통해 적어도 하나의 read 또는 write 규칙을 부여하면 저장소가 나타납니다. 빌드만 가져오면 되는 playtester 라면, 조치할 곳은 여기가 아닙니다: 빌드 접근 을 참조하세요.

두 규칙이 서로 모순된다

가장 구체적인 것（가장 깊은 깊이）이 이깁니다. 어느 것이 결정하는지는 테스트 로 확인하세요.

none 규칙이 있는데도 lead가 쓰기 상태로 남는다

admin 과 lead 역할은 경로 규칙을 우회합니다（어디서나 write）. none 규칙으로도 제한되지 않습니다. project_admin 이 자신의 저장소에 대해 갖는 경우도 마찬가지입니다.

그룹을 통한 접근과 직접 접근

접근은 계정 자체에서 오거나, 소속된 그룹 에서 올 수 있습니다. 규칙을 제거해도 아무것도 바뀌지 않으면, 다른 소스를 찾으세요（어느 것이 적용되는지는 테스트가 알려줍니다）.