Permissões

Introdução

A aba Permissions define, para um repositório específico, quem pode ler ou escrever em quais pastas. Uma permissão tem como alvo um grupo ou um usuário, aplica-se a um padrão de caminho e carrega um nível (write / read / none). A função diz o que uma conta pode fazer; a permissão diz sobre quais arquivos.

Acesso e funções

A aba está disponível para o super admin (todos os repositórios) e para o project_admin (os repositórios que ele administra). As regras estão sempre vinculadas ao repositório selecionado.

Os três painéis da aba

A aba Permissions fica na linha PROJECT do painel de administração: tudo o que você faz ali vale apenas para o repositório mostrado no seletor, no topo da linha. A linha SERVER, logo acima, diz respeito, ao contrário, ao servidor inteiro, e é ali que vivem as contas e os grupos.

A aba empilha três painéis distintos, de cima para baixo. Eles respondem a três perguntas diferentes, e confundir os dois primeiros com a árvore de pastas é a causa de chamado mais frequente nesta página.

O restante desta página descreve primeiro a árvore de permissões, que é o painel principal, e depois os outros dois.

Os três níveis

Conceder um acesso

1. Abrir a aba Permissions no projeto certo

Linha PROJECT, seletor de repositório no topo da linha: verifique o projeto mostrado antes de tudo, as regras ficarão vinculadas somente a ele.

2. Escolher o sujeito

No seletor, pegue um grupo ou um usuário: a lista é dividida em duas sublistas, Groups e Users. Uma regra visa um ou outro, nunca ambos. Enquanto nenhum sujeito for escolhido, o botão Apply permanece inativo.

3. Marcar as pastas

Na árvore de pastas, marque as que estão em questão. As caixas têm três estados (tudo, parcial, nada), e o campo Filter folders... reduz a árvore quando o projeto é grande.

4. Escolher o nível e aplicar

Uma barra aparece assim que uma pasta é marcada: ela informa o número de pastas selecionadas e oferece os três níveis (write, read, none). Escolha um e clique em Apply. As regras do sujeito aparecem então abaixo, na tabela Active rules (Path Pattern, Permission, Priority), onde você pode excluí-las uma a uma.

Conceder por nome de usuário

O botão "+ By username" permite conceder acesso a alguém que não aparece na lista visível, digitando seu nome exato. É a maneira de conceder acesso a uma conta fora do seu escopo habitual, por exemplo um playtester que ainda não possui nenhuma permissão.

O nome deve corresponder exatamente (sem prefixo). O campo retorna apenas o identificador e o nome, nunca a função, para não servir para sondar as contas existentes.

Padrões e prioridade

Uma regra não visa um arquivo específico, mas um padrão de caminho, o que se chama de glob: uma notação abreviada em que * substitui qualquer sequência de caracteres em um nome, e ** qualquer sequência de pastas, em qualquer profundidade. Assim, Content/Maps/** designa tudo o que está sob Content/Maps, subpastas incluídas. Você não precisa escrevê-los à mão: marcar uma pasta na árvore produz o glob correspondente.

Uma pasta marcada Foo/Bar torna-se o padrão Foo/Bar/** (a pasta e tudo o que ela contém, em qualquer profundidade). A raiz do repositório torna-se /**.

Cada regra recebe uma prioridade automática igual à profundidade da pasta (número de segmentos, raiz = 0). Uma regra mais específica (mais profunda) prevalece, portanto, sobre uma mais geral. Exemplo: write em Content/** e none em Content/Secret/** dá acesso de escrita em todo Content/ exceto em Secret/.

Resolução padrão

Quando nenhuma regra explícita cobre um caminho, o acesso efetivo segue este modelo:

• Por padrão, o acesso é read (leitura) quando nenhuma regra corresponde.
• admin e lead têm write em toda parte (contorno de função).
• Um project_admin tem write nos repositórios que administra e nada de especial em outros lugares.
• Caso contrário, aplica-se a regra mais específica; na falta dela, a leitura padrão.

Em outras palavras: para proibir a leitura de uma pasta a alguém que já tem acesso ao repositório, não basta não conceder nada (o padrão é read), é preciso uma regra none explícita.

Consequência prática, e que evita trabalho inútil: um projeto novo sem nenhuma regra já está fechado para todo mundo, exceto para as funções admin e lead e para seus próprios project_admins. Portanto não é necessário colocar regras none por toda parte para "fechar" um projeto; basta conceder apenas o que você quer abrir. As regras none servem para recortar dentro de um acesso já concedido, por exemplo para ocultar Content/Secret/ de uma equipe que tem Content/.

Nomear um administrador de projeto

O painel Project Admins, no topo da aba, designa quem administra o repositório selecionado. Ele é reservado ao super admin: conceder a autoridade está um degrau acima de exercê-la.

O procedimento tem duas etapas, nesta ordem:

1. Dar a função, na aba Users

Linha SERVER, aba Users: dê à pessoa a função project_admin. Enquanto essa função não for atribuída, ela não aparece na lista deste painel, que aliás avisa: "No one to add. Give someone the Project Admin role on the Users tab first".

2. Vincular a pessoa ao repositório

Volte aqui, verifique o repositório mostrado no seletor da linha PROJECT, e então, no painel Project Admins, clique em Add, escolha a pessoa e clique em Grant. Ela aparece imediatamente na lista do painel.

Remover um vínculo

A cruz vermelha no fim da linha (Revoke) remove o repositório do escopo dela. A função sem o vínculo não dá nada: um project_admin que não administra mais nenhum repositório perde o acesso a Permissions, Rules, Webhooks, Files e à gestão de usuários. Remover o último repositório remove, portanto, toda a autoridade.

Acesso às builds

O painel Build Access decide quem pode ver e baixar as builds publicadas deste projeto na página Games do cliente. Ele é aberto ao super admin e ao project_admin em seus repositórios.

1. Abrir o formulário de adição

No painel Build Access, clique em Add. Uma linha de entrada aparece, começando pela escolha de como designar o destinatário.

2. Designar o destinatário

• User: uma conta da lista, ou seja, alguém que já trabalha no projeto.
• Group: um grupo inteiro, prático para uma turma de estudantes ou uma equipe de teste recorrente.
• By username: um campo Exact username onde você digita o nome exato da conta. É a via normal para um playtester, já que ele não figura em nenhuma lista. O nome deve corresponder exatamente, sem prefixo.

3. Conceder ou revogar

Clique em Grant para conceder. Em uma linha existente, Revoke remove o acesso, com uma confirmação.

A regra aplicada pelo servidor, em ordem:

Em outras palavras: quem já trabalha no projeto não precisa de mais nada aqui. Este painel serve às pessoas externas ao projeto, e um viewer permanece excluído em todos os casos.

Testar uma permissão

O painel Test Permission, no fim da aba, responde a "qual acesso efetivo este usuário tem sobre este caminho?". É a maneira mais curta de saber qual das suas regras realmente decide.

1. Escolher o usuário e o caminho

Pegue uma conta em User, depois digite um caminho em Path, por exemplo /Content/Maps/Level01.umap. O botão permanece inativo enquanto ambos não forem preenchidos.

2. Executar o teste e ler o resultado

Clique em Test. O resultado mostra o nível efetivo, bem como a fonte e o padrão que decidiram, o que permite entender por que um acesso é concedido ou negado.

Para um usuário que você não tem o direito de ver, o teste retorna o mesmo "não encontrado" de uma conta inexistente, para não revelar a existência das contas.

Armadilhas comuns

"Não concedi nada, mesmo assim ele consegue ler"

É o padrão read, e ele só atua dentro de um repositório ao qual a pessoa já tem acesso. Para fechar uma pasta a alguém que trabalha no projeto, coloque uma regra none explícita sobre ela.

"O repositório não aparece na lista dele"

É normal enquanto ele não tiver nenhuma regra além de none sobre este repositório. O padrão read não dá acesso ao repositório em si. Conceda-lhe pelo menos uma regra read ou write, diretamente ou via um grupo, e o repositório aparecerá. Se for um playtester que só precisa obter as builds, não é aqui que se deve agir: veja Acesso às builds.

Duas regras se contradizem

A mais específica (maior profundidade) vence. Use o teste para ver qual decide.

Um lead permanece com escrita apesar de uma regra none

As funções admin e lead contornam as regras de caminho (write em toda parte). Uma regra none não as restringe. O mesmo para um project_admin em seus próprios repositórios.

Acesso via grupo vs. acesso direto

Um acesso pode vir da própria conta ou de um grupo do qual ela é membro. Se remover uma regra não muda nada, procure a outra fonte (o teste indica qual se aplica).