Breaking: #97265 - Simplified access mode system¶
See Issue #97265
In preparation of a deployable backend access rights system based on configuration files, some rarely used details of the permission system have been streamlined and simplified:
- The global configuration option
TYPO3_CONF_VARS['BE']['explicitADmode']has been removed and is not evaluated anymore.
- The only valid value for TCA config option
'type' => 'select'fields is now
explicitAllow. The values
individualare invalid and no longer evaluated.
- With removal of
authMode' => 'individual'for TCA select fields, the sixth
itemsoption is obsolete and removed. The values
EXPL_DENYare without any effect.
- Handling of TCA config option
authMode_enforcehas been removed.
- The fourth tuple of
explicit_allowdenythat was previously set to either
- The fourth argument on
BackendUserAuthentication->checkAuthMode()has been removed.
Using any of the above removed options will log deprecation level error messages.
individual as value for TCA config option
authMode is no longer supported by the system and may need manual
may lead to a PHP warning level error.
- Instances with extensions using
$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']. The extension scanner will typically find affected instances.
- Instances with TCA select fields using
'authMode' => 'explicitDeny'.
- Instances with TCA select fields using
'authMode' => 'individual'and select items being set to
EXPL_DENY. This is a very rarely used option and it’s unlikely modern extensions use this in practice: There is not a single extension in the TER using this option combination and it’s unlikely to be used in custom extensions, either.
- Instances manually dealing with the
be_groupsmay be affected if they expect the fourth field being set to
DENY. This is unlikely since the core provides an API for this field using
- Instances calling
BackendUserAuthentication->checkAuthMode()with four instead of three arguments. The extension scanner will find usages as weak match.
- Instances using
'type' => 'select'fields.
The majority of instances does not need to take care of anything. The values of the database
explicit_allowdeny for table
be_groups are updated with an upgrade wizard.
This should be executed. The following parts of this section outline options for rare cases
if specific seldom used options are used.
The handling of
$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode'] has been changed as
if it is always set to
explicitAllow. Extensions should not assume this global array
key being set anymore since TYPO3 core v12. Extensions that need to stay compatible with v11
and v12 should fall back:
$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode'] ?? 'explicitAllow'.
Extensions with select fields using
authMode previously had different handling
authMode_enforce => 'strict' has been set: Let’s say an editor accesses a record
authMode field being set to a value it has no access to. With
not being set to
strict, the editor was still able to edit the record and set the value
to something it had access to. With
authMode_enforce being set to
strict, the editor
was not allowed to access the record. This has been streamlined: The backend interface no longer
renders those records for the editor and an “access denied” message is rendered instead. To
prevent this, a group this editor is member of needs to be adapted to allow access to this
particular value in the “Explicitly allow field values” (
The “deny list” approach for single field values has been removed, the only allowed option
explicitAllow. Extensions using config value
should be adapted to switch to
explicitAllow instead. The upgrade wizard
“Migrate backend groups “explicit_allowdeny” field to simplified format.” that transfers
be_groups rows to the new format drops any
DENY fields and instructs
admins no set new access rights of affected backend groups.
authMode being set to
individual has been fully dropped. There is
no core-provided alternative. This has been an obscure setting since ever and there is no
direct migration. Extension that rely on this handling need to find a substitution based on
core hooks, core events or other existing core API functionality.