Разрешения

Введение

Вкладка Permissions определяет для заданного репозитория, кто может читать или записывать в какие папки. Разрешение нацелено на группу или пользователя, применяется к шаблону пути и несёт уровень (write / read / none). Роль говорит, что может делать учётная запись; разрешение говорит, над какими файлами.

Доступ и роли

Вкладка доступна суперадминистратору (все репозитории) и project_admin (репозитории, которыми он управляет). Правила всегда привязаны к выбранному репозиторию.

Три панели вкладки

Вкладка Permissions находится в ряду PROJECT панели администрирования: всё, что вы делаете здесь, действует только для репозитория, показанного в селекторе в начале ряда. Ряд SERVER, прямо над ним, напротив, касается всего сервера, и именно там находятся учётные записи и группы.

Вкладка складывает три отдельные панели, сверху вниз. Они отвечают на три разных вопроса, и спутать первые две с деревом папок — самая частая причина обращений на этой странице.

Остальная часть этой страницы описывает сначала дерево разрешений, которое является главной панелью, затем две другие.

Три уровня

Предоставление доступа

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). Поэтому более конкретное (более глубокое) правило берёт верх над более общим. Пример: write на Content/** и none на Content/Secret/** даёт доступ на запись всюду в Content/, кроме Secret/.

Разрешение по умолчанию

Когда ни одно явное правило не покрывает путь, эффективный доступ следует этой модели:

• По умолчанию доступ равен read (чтение), когда ни одно правило не совпадает.
• admin и lead имеют write везде (обход по роли).
• project_admin имеет write на репозиториях, которыми управляет, и ничего особого в других местах.
• В противном случае применяется самое конкретное правило; при его отсутствии, чтение по умолчанию.

Иными словами: чтобы запретить чтение папки тому, у кого уже есть доступ к репозиторию, недостаточно ничего не предоставлять (по умолчанию read), нужно явное правило none.

Практическое следствие, и оно избавляет от ненужной работы: новый проект без единого правила уже закрыт для всех, кроме ролей admin и lead и его собственных project_admin. Поэтому не нужно расставлять правила none повсюду, чтобы «закрыть» проект; достаточно предоставить только то, что вы хотите открыть. Правила none служат для разграничения внутри уже предоставленного доступа, например чтобы скрыть Content/Secret/ от команды, у которой есть Content/.

Назначение администратора проекта

Панель 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 убирает доступ, с подтверждением.

Правило, применяемое сервером, по порядку:

Иными словами: тому, кто уже работает над проектом, здесь больше ничего не нужно. Эта панель служит людям вне проекта, а viewer остаётся исключён в любом случае.

Проверка разрешения

Панель Test Permission, в самом низу вкладки, отвечает на вопрос «какой эффективный доступ у этого пользователя к этому пути?». Это самый короткий способ узнать, какое из ваших правил на самом деле решает.

1. Выбрать пользователя и путь

Возьмите учётную запись в User, затем введите путь в Path, например /Content/Maps/Level01.umap. Кнопка остаётся неактивной, пока не заполнены оба поля.

2. Запустить проверку и прочитать результат

Нажмите Test. Результат показывает эффективный уровень, а также источник и шаблон, которые приняли решение, что позволяет понять, почему доступ предоставлен или отклонён.

Для пользователя, которого вы не вправе видеть, проверка возвращает то же «не найдено», что и для несуществующей учётной записи, чтобы не раскрывать существование учётных записей.

Частые ошибки

«Я ничего не предоставлял, а он всё равно может читать»

Это умолчание read, и оно действует только внутри репозитория, к которому у человека уже есть доступ. Чтобы закрыть папку тому, кто работает над проектом, поставьте на неё явное правило none.

«Репозиторий не появляется в его списке»

Это нормально, пока у него нет ни одного правила, кроме none, на этом репозитории. Умолчание read не даёт доступа к самому репозиторию. Предоставьте ему хотя бы одно правило read или write, напрямую или через группу, и репозиторий появится. Если это playtester, которому нужно только получить сборки, действовать нужно не здесь: см. Доступ к сборкам.

Два правила противоречат друг другу

Побеждает самое конкретное (наибольшая глубина). Используйте проверку, чтобы увидеть, какое из них решает.

Lead остаётся с записью несмотря на правило none

Роли admin и lead обходят правила путей (write везде). Правило none их не ограничивает. То же и для project_admin на его собственных репозиториях.

Доступ через группу против прямого доступа

Доступ может исходить от самой учётной записи или от группы, в которой она состоит. Если удаление правила ничего не меняет, ищите другой источник (проверка укажет, какой применяется).