be_acl para TYPO3

Quando mais de três editores trabalham, as permissões padrão do TYPO3 não são mais suficientes

O TYPO3 traz um sistema de permissões: grupos de backend, acessos a páginas, permissões de tabelas. Para equipes pequenas com poucos editores, funciona. Mas quando um site corporativo é mantido por 15 editores de 4 departamentos, o sistema padrão atinge seus limites. be_acl estende o TYPO3 com Listas de Controle de Acesso granulares que regulam, por página e para qualquer número de usuários e grupos, quem pode ver, editar ou excluir o quê ali.

A extensão não é um luxo, mas pré-requisito para qualquer configuração com múltiplos editores e mais de uma zona de responsabilidade. Sem be_acl, conceitos de permissão no TYPO3 regularmente terminam em uma rede de dezenas de grupos que ninguém mais consegue acompanhar.

Cenários típicos de uso

Sites corporativos com responsabilidade por departamento. Marketing cuida da página inicial e páginas de campanha, RH da página de carreiras, os departamentos técnicos de suas páginas de produtos. Cada departamento deve ver e editar apenas suas próprias páginas. O sistema padrão do TYPO3 permite acessos a páginas via Mount Points e permissões de grupo, mas a configuração fica confusa com mais de 10 departamentos. be_acl simplifica isso com ACLs baseadas em página: em cada página da árvore de páginas, é possível definir diretamente qual grupo tem quais permissões.

Instalações TYPO3 multi-tenant. Agências e corporações operam vários sites em uma instância TYPO3. O mandante A não deve ver o mandante B, nem na árvore de páginas. be_acl aplica essa separação sem precisar operar uma instalação TYPO3 separada para cada mandante. Em uma agência com 12 mandantes em uma instância TYPO3, be_acl reduziu o tempo de administração de permissões em cerca de 60%.

Workflows de aprovação com profundidade de edição limitada. Prestadores de serviço externos ou estagiários devem editar textos de conteúdo, mas não fazer upload de imagens, mover páginas ou configurar plugins. As permissões no nível de campo vêm do Core do TYPO3: pelos campos permitidos do seu grupo de backend, o usuário vê o campo de texto, mas não as configurações de layout ou a configuração do plugin. be_acl complementa isso com as permissões de página adequadas, por exemplo editar conteúdos, mas não criar nem excluir páginas.

Arquitetura técnica

be_acl estende o sistema de permissões de backend do TYPO3 com uma camada ACL que se situa entre o sistema de permissões do Core e a interação do usuário. A extensão armazena regras de permissão na tabela tx_beacl_acl, que define por página e por grupo quais operações são permitidas.

O sistema trabalha com as cinco permissões de página do TYPO3: mostrar a página (show), editar a página, excluir a página, criar subpáginas e editar conteúdos. Essas permissões são concedidas por página ou recursivamente para uma árvore de páginas. A configuração é feita no módulo de backend Web > Access: ali o administrador cria para uma página uma ACL para um usuário ou um grupo e define as permissões desejadas via checkbox.

Internamente, be_acl intervém no BackendUserAuthentication do TYPO3 e estende a verificação doesUserHaveAccess. A cada acesso a página no backend, o TYPO3 verifica primeiro as permissões padrão e depois as regras ACL. As regras ACL podem estender permissões padrão, mas não restringi-las. Esse é um detalhe arquitetural importante: se um grupo já tem acesso pelas permissões padrão, be_acl não pode revogar esse acesso.

A resolução de permissões segue duas regras. Primeiro, para o usuário e para cada um de seus grupos vale a ACL mais próxima da página: uma ACL na própria página ou a próxima ACL recursiva acima dela. Segundo, o be_acl soma as permissões das ACLs de usuário e de grupo (combinação OU) e, com o sistema de permissões antigo ativo, também as permissões clássicas de página; assim, um grupo não consegue retirar permissões de outro.

Problemas frequentes e soluções

Permissões não funcionam como esperado. Causa mais frequente: o usuário é membro de vários grupos, e as permissões de um grupo sobrescrevem a restrição ACL de outro. O sistema de permissões do TYPO3 funciona de forma aditiva, ou seja, o usuário recebe a soma de todas as permissões de seus grupos. Solução: criar uma matriz de permissões, documentar todos os grupos de um usuário e eliminar sobreposições.

Problemas de performance em árvores de página grandes. A partir de cerca de 1.000 páginas, o cálculo das ACLs se torna perceptível, segundo a documentação, sobretudo ao criar elementos de conteúdo e ao editar as propriedades da página; a carga cresce com o número de subpáginas às quais uma ACL se aplica. O be_acl já guarda esses cálculos em cache, se desejado no Redis. Solução: não colocar ACLs na página raiz, conceder permissões globais pelo sistema de permissões clássico e usar ACLs só para subárvores.

Debug de permissões é difícil. O TYPO3 não oferece uma ferramenta nativa que mostre por que um usuário pode ou não acessar determinada página. A área de Admin “Backend User” mostra a visualização simulada, mas não a cascata de permissões. Solução: analisar o System Log do TYPO3 (com modo debug ativado, o TYPO3 registra tentativas de acesso) ou consultar diretamente a tabela SQL tx_beacl_acl.

Migração e compatibilidade de versões

Desde janeiro de 2021 não saiu nenhuma versão nova do be_acl. A última versão, 2.0.1, suporta apenas o TYPO3 v10; para v11, v12 e v13 não há release.

Quem migra do TYPO3 v10 para uma versão mais nova precisa, portanto, portar o be_acl por conta própria ou passar as permissões para os recursos do Core. As regras existentes na tabela tx_beacl_acl são a base para isso; ao portar para a v12 ou posterior, entra ainda o novo registro de módulos de backend.

Para empresas que migram para TYPO3 v13, recomenda-se exportar as regras ACL existentes antes do upgrade. O TYPO3 v13 reformula a gestão de permissões no backend, mas não incorpora nenhuma função do be_acl: também o Core da v13 não permite que vários grupos tenham permissões próprias na mesma página. Se o conceito de permissões pode ser reproduzido com as permissões do Core depende da sua complexidade. A Gosign analisa em upgrades TYPO3 a configuração ACL existente e recomenda a solução ideal - seja be_acl, permissões nativas do Core ou uma combinação.