Разрешения

Введение

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

Доступ и роли

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

Три уровня

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

1. Выберите репозиторий, затем вкладку Permissions.
2. Выберите субъект в селекторе: группу или пользователя (два подсписка "Groups" и "Users"). Правило нацелено на одного или на другого, никогда на обоих.
3. В дереве папок отметьте нужные папки (флажки имеют три состояния: всё / частично / ничего). Поле поиска фильтрует дерево.
4. В появившейся панели выберите уровень (write / read / none) и нажмите Apply.

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

Предоставление по имени пользователя

Кнопка "+ By username" позволяет предоставить доступ тому, кто не отображается в видимом списке, введя его точное имя. Это способ предоставить доступ учётной записи за пределами вашей обычной области, например playtester, который ещё не имеет ни одного разрешения.

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

Шаблоны и приоритет

Отмеченная папка Foo/Bar становится шаблоном Foo/Bar/** (папка и всё, что она содержит, на любой глубине). Корень репозитория становится /**.

Каждое правило получает автоматический приоритет, равный глубине папки (число сегментов, корень = 0). Поэтому более конкретное (более глубокое) правило берёт верх над более общим. Пример: write на Content/** и none на Content/Secret/** даёт доступ на запись всюду в Content/, кроме Secret/.

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

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

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

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

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

Панель Test Permission отвечает на вопрос «какой эффективный доступ у этого пользователя к этому пути?». Выберите пользователя, введите путь (например /Content/Maps/Level01.umap) и запустите проверку. Результат показывает эффективный уровень, а также источник и шаблон, которые приняли решение, что позволяет понять, почему доступ предоставлен или отклонён.

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

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

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

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

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

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

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

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

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

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