Papéis e permissões
Imagine que você atribuiu o colega minji.kim@example.com ao Space da loja de roupas. Você quer confiar a ele o cadastro e a edição de produtos, mas fica receoso de também confiar a exclusão de produtos ou a publicação externa. Esse conjunto de permissões que define "o que um membro pode e o que não pode fazer dentro de um Space" é o SpaceRole.
Em vez de atribuir permissões a cada membro individualmente, o SpaceRole funciona criando antecipadamente um conjunto de permissões e anexando-o aos membros. Por exemplo, se você criar uma única vez um papel que "só pode ler e editar produtos", basta anexar esse único papel aos colegas que vão cuidar do cadastro de produtos. Mesmo que o número de membros aumente, você não precisa definir as permissões do zero a cada vez.
Nesta página, primeiro vamos ver o que é o SpaceRole e quais permissões ele contém, e depois criar você mesmo um papel de "responsável pelo cadastro de produtos" no Space da loja de roupas.
O papel de Space é diferente do papel de Organization
No WEEGLOO há dois lugares onde as permissões são definidas. Como é fácil confundir, primeiro vamos traçar a fronteira.
- O papel de Organization (Owner, Admin, Member) é o nível dentro da empresa inteira. Define quem pode realizar tarefas que abrangem toda a Organization, como convidar membros ou criar um novo Space.
- O SpaceRole é a permissão dentro de um Space específico. Define até onde um membro pode ir ao lidar com conteúdo dentro daquele espaço de trabalho, como criar, editar e publicar produtos.
Você pode dar a um mesmo colega um SpaceRole diferente em cada Space. No Space da loja online, ele pode até editar produtos; no Space de avisos internos, ele só pode ler. Esta página trata apenas do SpaceRole. O papel de Organization e o convite e a atribuição de membros são tratados em Organização e Space.
O que cabe em um papel: sobre o quê, qual ação
Um único SpaceRole contém "sobre qual alvo, qual ação, permitir ou negar".
Primeiro, os alvos sobre os quais a permissão é definida são de quatro tipos. O quarto, Script, tem ações diferentes e é tratado à parte mais adiante. Os três a seguir compartilham o mesmo conjunto de ações:
- Content Type: o molde de formulário, como produto ou aviso
- Content: cada produto criado a partir desse molde
- Media: arquivos enviados, como fotos e vídeos
As ações que podem ser permitidas ou negadas para cada alvo são as seguintes.
As ações são exibidas em inglês na tela. O significado de cada ação é o seguinte.
| Ação (texto na tela) | O que faz |
|---|---|
| Read | Vê a lista e o conteúdo |
| Create | Cria algo novo |
| Edit | Altera e salva algo que já existe |
| Delete | Apaga |
| Publish | Publica para que fique disponível externamente (entrega) |
| Unpublish | Retira a publicação e interrompe a disponibilização externa |
| Archive | Move para o estado arquivado |
| Unarchive | Restaura do arquivamento |
| All actions | Permite todas as ações acima de uma só vez |
Aplicando ao exemplo da loja de roupas, no papel de "responsável pelo cadastro de produtos" você seleciona as ações assim: para Content (produtos), permite Read, Create e Edit, e não inclui Delete nem Publish. Dessa forma, o colega pode criar e alterar produtos, mas não pode apagá-los nem disponibilizá-los externamente.
O que é Publish e como, ao publicar, o conteúdo fica disponível externamente (entrega) são tratados em detalhe em Estados e publicação.
Permitir e negar
Na tela do papel há uma lista de Permitido e uma lista de Negado separadas. A forma de fazer é colocar, uma linha por vez, na lista de Permitido, a ação que você quer habilitar. O ponto importante é que uma ação que não for colocada na lista de permissão é automaticamente negada. Por isso, basta colocar em permissão apenas as ações que você quer conceder ao colega; as demais ficam bloqueadas sem que seja preciso bloqueá-las separadamente.
A lista de Negado é um mecanismo de segurança usado "quando você quer permitir de forma ampla, mas bloquear apenas uma parte específica como exceção". Quando uma ação está ao mesmo tempo em permissão e em negação, a negação sempre prevalece.
Restringir o escopo a um tipo específico ou a uma pessoa específica
Ao permitir uma ação, você pode restringir essa permissão apenas a um tipo ou a uma condição específica. Por exemplo, são possíveis as seguintes restrições.
- Apenas a um tipo: aplica apenas ao Content Type "Produto" e não aplica aos demais Content Type.
- Apenas ao que ele mesmo criou: faz com que o membro só possa lidar com o Content que ele próprio criou, e não possa tocar no que outros criaram.
- Apenas ao que tem uma Tag específica: aplica apenas ao Content ou à Media que têm uma Tag determinada.
Se você não restringir o escopo, a ação se aplica a todo o alvo correspondente. Por exemplo, se você permitir a leitura de Content sem restringir, será possível ler todos os Content; se restringir ao Content Type "Produto", será possível ler apenas os produtos.
O que é uma Tag é tratado em Tag.
Permissões de execução e gerenciamento de Script
Além dos três alvos acima, um SpaceRole também contém permissões para Script. Um Script é um endpoint de backend que o frontend chama, criado sem código de servidor (consulte Script). Ele tem uma ação Execute que Content e Media não têm.
- Execute: permite que alguém execute (chame) aquele Script. O frontend, ou um membro cadastrado, precisa dessa permissão para chamar um Script.
- Read, Create, Edit, Delete: as permissões de gerenciamento para consultar, criar, alterar e excluir um Script.
Você pode restringir isso por autor, de modo que um membro lide "apenas com os Script que ele mesmo criou". Não há ação de publicação, porque um Script não é um recurso que se publica. Para os membros que se cadastram no seu produto (ServiceUser), normalmente você abre apenas Execute, já que a autoria, ou seja, criar e alterar Script, fica a cargo dos usuários do estúdio de conteúdo.
O formato exato das regras de permissão é tratado nas referências da API SpaceRole e ServiceUserRole.
O papel também decide se as configurações do Space podem ser alteradas
Até aqui, tratamos das permissões para lidar com conteúdo e Script. O papel contém mais uma lista, de natureza diferente. Ela diz respeito a poder ou não alterar as configurações do Space.
Voltando ao exemplo da loja de roupas, você provavelmente quer confiar ao colega o cadastro de produtos, mas não quer confiar também a adição de um novo Locale nem a emissão de um token para um site externo usar. Quem pode fazer esse tipo de trabalho de configuração do Space é o que esta lista define.
Diferentemente das permissões anteriores, esta lista não tem ações nem restrição de escopo. Se você ativar um item, pode lidar com aquela configuração; se não ativar, não pode. Ativa-os e desativa-os no separador Permissions do ecrã onde cria ou edita um perfil. Ao ativar Todos os Permissions de gestão no topo, todos os itens abaixo são ativados de uma vez, e ativar os itens um a um também mostra este botão como ativado. Os itens que você pode ativar são os seguintes.
| Item | O que passa a ser possível ao ativar |
|---|---|
| Gerir informações do Space | Altera o nome e a descrição do Space |
| Gerir adesões | Adiciona e remove membros deste Space e altera o papel de um membro |
| Gerir Roles | Cria e altera papéis, como você faz nesta página |
| Gerir Delivery Access Tokens | Emite e gerencia tokens somente leitura |
| Gerir Space Access Tokens | Emite e gerencia tokens de leitura e escrita |
| Gerir Locales | Adiciona um idioma ou altera o idioma padrão |
| Gerir Email Accounts | Registra a conta remetente usada no envio de e-mails |
| Gerir apps | Traz um aplicativo do marketplace e o instala |
| Gerir Tags | Cria, altera e exclui Tag |
| Gerir Web Hostings | Implanta um site e conecta um domínio |
| Gerir ServiceLogin | Configura o login e as permissões dos membros que se cadastram no seu produto |
| Gerir Webhooks | Cria Webhook e vê o histórico de chamadas |
| Gerir Schedulers | Cria Scheduler e vê o histórico de execuções |
| Ver monitorização | Vê o armazenamento e o tráfego que este Space usou |
Note que os dois tipos de token são itens separados. Você pode permitir a emissão apenas do Delivery Access Token, que é somente leitura, e bloquear a emissão do Space Access Token, que também escreve. Você faz essa separação quando quer que o próprio colega emita o token de leitura que vai no site público, mas que só um administrador crie o token que também permite escrita.
O item Gerir Schedulers não é suficiente por si só. Ao criar ou alterar um Scheduler, você também precisa ter a permissão Execute do Script que ele vai executar (consulte Com a permissão de quem ele é executado).
Se você não ativar nenhum item, o papel se torna um papel que lida apenas com conteúdo. É o caso do papel "responsável pelo cadastro de produtos" que vamos criar mais adiante: ele pode cadastrar e alterar produtos, mas não consegue tocar em nenhuma configuração do Space.
O papel Administrator que vem junto quando você cria um Space
Quando você cria um novo Space, um papel chamado Administrator é criado automaticamente junto. Esse papel é o papel de permissão máxima, capaz de lidar com tudo dentro daquele Space. Quem cria o Space começa com esse papel Administrator.
O papel Administrator é um papel preparado pelo sistema, por isso não pode ser editado nem excluído. Se você quiser restringir as permissões e dar a um colega, em vez de alterar o Administrator, basta criar um novo papel separado como abaixo e concedê-lo.
Criar o papel "responsável pelo cadastro de produtos"
Agora vamos criar você mesmo, no Space da loja de roupas, o papel "responsável pelo cadastro de produtos" para dar a um colega. Vamos fazer com que esse papel possa Read, Create e Edit os produtos (Content), mas não possa excluí-los nem publicá-los.
- No menu à esquerda, clique em Roles e Permissions.
- Clique no botão Criar no canto superior direito da lista.
- No campo de nome da aba Detalhes do Role, digite
Cadastro de produtos. O campo de descrição pode ficar em branco.
Em seguida, defina as ações que esse papel pode realizar sobre os produtos (Content). As ações são adicionadas como regras, uma linha por vez, na lista de Permitido, e na mesma linha você também escolhe o escopo de aplicação (Content Type).
- Vá para a aba Content.
- Em Permitido, clique no + para adicionar uma linha de regra.
- Nessa linha, escolha a ação como Read e o Content Type a ser aplicado como "Produto". (Se deixar os campos de autor e Tag como "Quaisquer…", a regra se aplica a tudo.)
- Da mesma forma, adicione também as regras Create e Edit, uma linha cada. Nas três linhas, deixe o Content Type como "Produto".
- Não coloque exclusão (Delete) nem publicação (Publish) em permissão. Como uma ação que não for colocada em permissão é automaticamente negada, o colega não poderá apagar os produtos nem disponibilizá-los externamente.
- Clique no botão Guardar no canto superior direito.
Quando "Cadastro de produtos" aparecer na lista, o papel foi criado. Ele aparece junto com o Administrator que já existia desde o início.
Dar o papel criado a um colega
Ter criado um papel não significa que ele se aplica automaticamente a alguém. O papel criado só tem efeito depois de ser anexado a um membro.
Ao atribuir um colega ao Space, você escolhe junto o papel que ele terá dentro daquele Space, e nesse momento basta escolher o "Cadastro de produtos" que você acabou de criar. Se o colega já estiver dentro do Space, você também pode aplicá-lo alterando o papel dele na lista de membros. Você também pode dar vários papéis a um único membro. Nesse caso, as ações permitidas por cada papel são todas somadas, e se uma ação for permitida em qualquer um dos papéis, o membro pode realizá-la. (A negação prevalecer sobre a permissão vale apenas dentro do mesmo papel. Mesmo que uma ação tenha sido negada em um papel, se outro papel a permitir, essa ação é possível.)
Os passos concretos para atribuir um membro ao Space e escolher o papel são tratados em Organização e Space.
O que fazer a seguir
- Organização e Space: atribua um colega ao Space e anexe o papel que você acabou de criar.
- Token: trata dos tokens de acesso que permitem que não uma pessoa, mas um site externo ou um programa, leia ou escreva conteúdo. O papel que você criou aqui também se anexa aos tokens. Anexado a um Delivery Access Token, o papel define o escopo de leitura daquele token; anexado a um Space Access Token, define o escopo de leitura e escrita. A permissão de emissão e gerenciamento é separada para cada um dos dois tokens, então você pode ativar apenas um deles na lista de configurações do Space acima.
- Referência da API: trata de especificações técnicas, como o formato das requisições necessárias para criar papéis diretamente em um programa ou para lidar com regras de permissão.