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 quem pode ver, editar ou excluir quais conteúdos em qual página - até o nível de campo.

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. be_acl permite permissões no nível de campo: o usuário vê o campo de texto, mas não as configurações de layout ou a configuração do plugin.

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 três níveis de permissão: Leitura (show), Edição (edit) e Exclusão (delete). Essas permissões são concedidas por página ou recursivamente para uma árvore de páginas. A configuração é feita por uma aba própria no diálogo de propriedades da página: ali o administrador seleciona um grupo de usuários 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 uma cascata: permissões de usuário sobrepõem permissões de grupo, permissões de grupo sobrepõem permissões de subgrupo, e ACLs específicas de página sobrepõem ACLs herdadas recursivamente. Essa cascata funciona de forma confiável enquanto a estrutura de grupos permanece plana. A partir de 4 níveis de grupo aninhados, o comportamento se torna difícil de prever.

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. Em instalações TYPO3 com mais de 5.000 páginas e mais de 20 grupos de usuários, a verificação ACL pode deixar a árvore de páginas do backend perceptivelmente mais lenta. A extensão verifica a tabela ACL a cada acesso a página. Solução: ativar cache das verificações ACL e restringir a árvore de páginas via options.pageTree.excludeDoktypes aos tipos de página relevantes.

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

be_acl é uma das extensões TYPO3 mantidas há mais tempo. A versão atual suporta TYPO3 v11 e v12. Para TYPO3 v13 existe uma versão beta baseada no novo sistema de módulos de backend. A extensão é desenvolvida ativamente no GitHub, os mantenedores respondem a issues.

Na migração do TYPO3 v11 para v12, as regras ACL não precisam ser migradas manualmente - a tabela do banco de dados permanece compatível. Porém, o registro de módulos de backend mudou na v12, pelo que o módulo de configuração be_acl requer uma atualização da versão da extensão.

Para empresas que migram para TYPO3 v13, recomenda-se exportar as regras ACL existentes antes do upgrade. TYPO3 v13 traz um sistema de permissões reformulado que incorpora algumas funções do be_acl no Core. Se a extensão ainda será necessária a longo prazo depende da complexidade do conceito de permissões. 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.