be_acl for TYPO3

Once more than three editors are involved, TYPO3’s standard permissions fall short

TYPO3 ships with a permission system of its own: backend groups, page access, table permissions. For small teams with a handful of editors, that works. But when a corporate website is maintained by 15 editors from 4 departments, the standard system hits its limits. be_acl extends TYPO3 with granular access control lists that define, per page and for any number of users and groups, who can see, edit or delete what there.

The extension is not a nice-to-have. It is a prerequisite for any multi-team editorial setup with more than one area of responsibility. Without be_acl, TYPO3 permission schemes regularly end up as a tangle of dozens of groups that nobody can keep track of.

Typical use cases

Corporate websites with departmental ownership. Marketing maintains the home page and campaign pages, HR the careers section, and the business units their product pages. Each department should see and edit only its own pages. Standard TYPO3 handles page access via mount points and group permissions, but the configuration becomes hard to follow once 10+ departments are involved. be_acl simplifies this with page-based ACLs: on every page in the page tree, you define directly which group has which permissions.

Multi-tenant TYPO3 installations. Agencies and large enterprises run several websites in one TYPO3 instance. Tenant A must not see tenant B, not even in the page tree. be_acl enforces this separation without requiring a separate TYPO3 installation per tenant. For an agency with 12 tenants in one TYPO3 instance, be_acl cut the time spent on permission administration by roughly 60%.

Approval workflows with limited editing depth. External contractors or interns should be able to edit copy, but not upload images, move pages or configure plugins. The field-level permissions come from the TYPO3 core: through the allowed fields of their backend group, the user sees the text field, but not the layout settings or the plugin configuration. be_acl adds the matching page permissions, for example editing content but not creating or deleting pages.

Technical architecture

be_acl adds an ACL layer to TYPO3’s backend permission system, sitting between the core permission logic and user interaction. The extension stores its permission rules in the tx_beacl_acl table, which defines per page and per group which operations are allowed.

The system works with TYPO3’s five page permissions: show page, edit page, delete page, create subpages and edit content. These permissions are granted per page or recursively for an entire branch of the page tree. Configuration happens in the Web > Access backend module, where the administrator adds an ACL for a user or a group to a page and sets the required permissions via checkboxes.

Internally, be_acl hooks into TYPO3’s BackendUserAuthentication and extends the doesUserHaveAccess check. On every page access in the backend, TYPO3 first checks the standard permissions and then the ACL rules. ACL rules can extend standard permissions but cannot restrict them. That is an important architectural detail: if a group already has access through the standard permissions, be_acl cannot revoke it.

Permission resolution follows two rules. First, for the user and for each of their groups, the ACL closest to the page applies: an ACL on the page itself or the nearest recursive ACL above it. Second, be_acl adds up the permissions from user and group ACLs (OR logic), on top of the classic page permissions while the old permission system is active, so one group cannot take away permissions that another grants.

Common problems and solutions

Permissions do not take effect as expected. The most common cause: the user belongs to several groups, and the permissions of one group override the ACL restriction of another. TYPO3’s permission system is additive, meaning a user receives the sum of the permissions of all their groups. The fix: build a permission matrix, document every group a user belongs to and eliminate the overlaps.

Performance issues with large page trees. According to the documentation, the ACL calculation becomes noticeable from around 1,000 pages, especially when creating content elements and editing page properties; the load grows with the number of subpages an ACL applies to. be_acl already caches these calculations, optionally in Redis. The fix: avoid ACLs on the root page, grant global permissions through the classic permission system and use ACLs only for subtrees.

Debugging permissions is difficult. TYPO3 has no built-in tool that shows why a user can or cannot access a particular page. The “Backend Users” admin module offers a simulated view, but not the permission cascade. The fix: analyze the TYPO3 system log (with debug mode enabled, TYPO3 logs access attempts) or query the tx_beacl_acl SQL table directly.

Migration and version compatibility

No new version of be_acl has been released since January 2021. The last version, 2.0.1, supports only TYPO3 v10; there is no release for v11, v12 or v13.

Anyone moving from TYPO3 v10 to a newer version therefore has to port be_acl themselves or switch the permissions to core features. The existing rules in the tx_beacl_acl table form the basis for this; when porting to v12 or later, the changed backend module registration has to be handled as well.

If you are moving to TYPO3 v13, export the existing ACL rules before the upgrade. TYPO3 v13 does rework permission management in the backend, but it does not take over any of be_acl’s functions: the v13 core still cannot give several groups their own permissions on the same page. Whether your permission model can be mapped with core permissions depends on how complex it is. During TYPO3 upgrades, Gosign analyzes the existing ACL setup and recommends the best fit: be_acl, core-native permissions or a combination of both.