Acesso de cliente no backend: que permissões são realmente necessárias

Um cliente deve poder gerir textos. O caminho mais rápido é um acesso de administrador — e o mais caro. Não porque alguém faça algo malicioso, mas porque um clique errado na área de plugins custa mais do que os dez minutos que uma função bem definida teria exigido.

O que o WordPress traz de origem

Na maioria dos casos, Editor é a resposta certa. Cobre totalmente os conteúdos e deixa a parte técnica de fora.

Onde o Editor continua a falhar

Há três coisas que regularmente faltam a um editor, e para cada uma existe uma resposta melhor do que «então que seja administrador»:

• Editar menus — requer uma permissão que normalmente cabe ao administrador e que pode ser atribuída de forma específica
• Usar construtores de páginas — muitos trazem permissões próprias que podem ser atribuídas individualmente
• Gerir formulários ou a loja — os próprios plugins definem permissões específicas para isso

O caminho é sempre o mesmo: acrescentar a permissão que falta, em vez de mudar de função. É exatamente para isso que existe uma matriz de permissões.

Arrumar é mais importante do que bloquear

Um backend com doze itens de menu, dez dos quais bloqueados, não é seguro, é confuso. O cliente procura, clica ao lado e telefona. As permissões dizem o que alguém pode fazer; igualmente importante é o que essa pessoa chega sequer a ver.

• Reduzir o menu de administração ao que é necessário
• Limitar a biblioteca de multimédia aos próprios ficheiros, quando vários clientes usam a mesma instalação
• Ocultar widgets e menus de navegação quando não dizem respeito a ninguém
• Depois do login, redirecionar para onde o trabalho começa — e não para o painel com cinco caixas de aviso

O teste que demora um minuto

As permissões não se podem avaliar no ecrã em que são definidas. Cria um utilizador de teste por função e inicia sessão como esse utilizador — num segundo browser, para que o teu próprio acesso continue aberto.

E para conteúdos protegidos há um segundo teste: termina a sessão e abre /wp-json/wp/v2/posts?search= com uma palavra do artigo protegido. Se o conteúdo aparecer na resposta, a tua regra só altera a vista — os dados estão expostos.

Este teste vale para qualquer plugin de permissões. «Ocultar» e «bloquear» são duas coisas diferentes, e só uma delas se aguenta.

Duas armadilhas quando há vários responsáveis

A primeira: quem pode atribuir permissões pode dar mais a si próprio. O WordPress tem uma salvaguarda para isso — get_editable_roles() —, e um plugin que a ignora abre precisamente o caminho que devia fechar.

A segunda diz respeito a redes multisite: aí, as funções estão em parte definidas ao nível da rede. Quem as sobrescreve a partir de um subsite altera-as para todos os sites — incluindo os que não lhe pertencem.

Na despedida

1. Desativar o acesso, não apagá-lo logo — caso contrário, os artigos perdem o autor.
2. Transferir os artigos para outra conta antes de apagar.
3. Revogar as palavras-passe de aplicação dessa conta; sobrevivem a uma alteração da palavra-passe.
4. Terminar as sessões ativas.
5. Anotar no registo de alterações quando e porquê.

Perguntas frequentes