be_acl para TYPO3

Cuando más de tres redactores trabajan, los permisos estándar de TYPO3 ya no son suficientes

TYPO3 trae un sistema de permisos: grupos de backend, accesos a páginas, derechos sobre tablas. Para equipos pequeños con un puñado de redactores funciona. Pero cuando un sitio web corporativo es mantenido por 15 redactores de 4 departamentos, el sistema estándar alcanza sus límites. be_acl amplía TYPO3 con Access Control Lists granulares que regulan, por página y para cualquier número de usuarios y grupos, quién puede ver, editar o eliminar qué en ella.

La extensión no es un complemento opcional, sino un requisito previo para cualquier configuración multi-redacción con más de una zona de responsabilidad. Sin be_acl, los conceptos de permisos en TYPO3 terminan regularmente en una maraña de docenas de grupos que nadie puede supervisar.

Escenarios de uso habituales

Sitios web corporativos con responsabilidad departamental. Marketing mantiene la página de inicio y las páginas de campañas, RRHH la página de empleo, los departamentos especializados sus páginas de producto. Cada departamento debe ver y editar solo sus propias páginas. El sistema estándar de TYPO3 permite accesos a páginas mediante Mount Points y derechos de grupo, pero la configuración se vuelve inmanejable con más de 10 departamentos. be_acl simplifica esto mediante ACLs basadas en páginas: en cada página del árbol de páginas se puede definir directamente qué grupo tiene qué derechos.

Instalaciones TYPO3 multi-tenant. Agencias y corporaciones operan múltiples sitios web en una sola instancia TYPO3. El mandante A no debe ver al mandante B, ni siquiera en el árbol de páginas. be_acl implementa esta separación sin necesidad de operar una instalación TYPO3 separada para cada mandante. En una agencia con 12 mandantes en una instancia TYPO3, be_acl redujo el tiempo de administración de permisos en aproximadamente un 60%.

Flujos de aprobación con profundidad de edición limitada. Proveedores externos o becarios deben editar textos de contenido, pero no subir imágenes, ni mover páginas, ni configurar plugins. Los derechos a nivel de campo proceden del Core de TYPO3: a través de los campos permitidos de su grupo de backend, el usuario ve el campo de texto, pero no los ajustes de diseño ni la configuración del plugin. be_acl lo completa con los derechos de página adecuados, por ejemplo editar contenidos pero no crear ni eliminar páginas.

Arquitectura técnica

be_acl amplía el sistema de permisos del backend de TYPO3 con una capa ACL que se sitúa entre el sistema de derechos del Core y la interacción del usuario. La extensión almacena reglas de permisos en la tabla tx_beacl_acl, que define por página y por grupo qué operaciones están permitidas.

El sistema trabaja con los cinco derechos de página de TYPO3: mostrar la página (show), editar la página, eliminar la página, crear subpáginas y editar contenidos. Estos derechos se asignan por página o recursivamente para un subárbol de páginas. La configuración se realiza en el módulo de backend Web > Access: allí el administrador crea para una página una ACL para un usuario o un grupo y establece los derechos deseados mediante casillas de verificación.

Internamente, be_acl interviene en la BackendUserAuthentication de TYPO3 y amplía la comprobación doesUserHaveAccess. Con cada acceso a una página en el backend, TYPO3 comprueba primero los derechos estándar y luego las reglas ACL. Las reglas ACL pueden ampliar los derechos estándar, pero no restringirlos. Este es un detalle arquitectónico importante: si un grupo ya tiene acceso a través de los derechos estándar, be_acl no puede revocarlo.

La resolución de derechos sigue dos reglas. Primera: para el usuario y para cada uno de sus grupos vale la ACL más cercana a la página, es decir, una ACL en la propia página o la siguiente ACL recursiva por encima. Segunda: be_acl suma los derechos de las ACL de usuario y de grupo (combinación OR) y, mientras el sistema de permisos antiguo esté activo, también los añade a los permisos de página clásicos; por tanto, un grupo no puede retirar derechos a otro.

Problemas frecuentes y soluciones

Los permisos no funcionan como se esperaba. Causa más frecuente: el usuario es miembro de varios grupos, y los derechos de un grupo sobrescriben la restricción ACL de otro. El sistema de derechos de TYPO3 funciona de forma aditiva, es decir, el usuario recibe la suma de todos los derechos de sus grupos. Solución: crear una matriz de permisos, documentar todos los grupos de un usuario y eliminar solapamientos.

Problemas de rendimiento con árboles de páginas grandes. Según la documentación, a partir de unas 1.000 páginas el cálculo de las ACL se nota, sobre todo al crear elementos de contenido y al editar las propiedades de página; la carga crece con el número de subpáginas a las que se aplica una ACL. be_acl ya guarda esos cálculos en caché, si se desea en Redis. Solución: no poner ACLs en la página raíz, conceder los derechos globales mediante el sistema de permisos clásico y usar ACLs solo para subárboles.

La depuración de derechos es difícil. TYPO3 no ofrece una herramienta integrada que muestre por qué un usuario puede o no acceder a una página determinada. El área Admin “Backend User” muestra la vista simulada, pero no la cascada de derechos. Solución: analizar el System Log de TYPO3 (con el modo Debug activado, TYPO3 registra los intentos de acceso) o consultar directamente la tabla SQL tx_beacl_acl.

Migración y compatibilidad de versiones

Desde enero de 2021 no se ha publicado ninguna versión nueva de be_acl. La última versión, 2.0.1, solo soporta TYPO3 v10; para v11, v12 y v13 no hay release.

Quien pase de TYPO3 v10 a una versión más reciente tiene que portar be_acl por su cuenta o trasladar los permisos a las herramientas del Core. Las reglas existentes en la tabla tx_beacl_acl son la base para ello; al portar a v12 o posterior hay que tener en cuenta además el cambio en el registro de módulos de backend.

Para empresas que migran a TYPO3 v13, se recomienda exportar las reglas ACL existentes antes de la actualización. TYPO3 v13 revisa la gestión de permisos en el backend, pero no incorpora ninguna función de be_acl: el Core de v13 tampoco permite que varios grupos tengan derechos propios en la misma página. Si el concepto de permisos puede reproducirse con los derechos del Core depende de su complejidad. Gosign analiza el setup ACL existente en las actualizaciones TYPO3 y recomienda la solución óptima, ya sea be_acl, derechos nativos del Core o una combinación.