Breaking: #97265 - Simplified access mode system¶
See forge#97265
Description¶
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
authMode
on'type' => 'select'
fields is nowexplicitAllow
. The valuesexplicitDeny
andindividual
are invalid and no longer evaluated. - With removal of
authMode' => 'individual'
for TCA select fields, the sixthitems
option is obsolete and removed. The valuesEXPL_ALLOW
andEXPL_DENY
are without any effect. - Handling of TCA config option
authMode_enforce
has been removed. - The fourth tuple of
be_groups
fieldexplicit_allowdeny
that was previously set to eitherALLOW
orDENY
is removed. - The fourth argument on
BackendUserAuthentication->checkAuthMode()
has been removed.
Impact¶
Using any of the above removed options will trigger a PHP E_USER_DEPRECATED
error.
Using explicitDeny
and individual
as value for TCA config option
authMode
is no longer supported by the system and may need manual
adaptions. Accessing $GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']
may lead to a PHP warning level error.
Affected Installations¶
- 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 toEXPL_ALLOW
orEXPL_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
explicit_allowdeny
of tablebe_groups
may be affected if they expect the fourth field being set toALLOW
orDENY
. This is unlikely since the Core provides an API for this field usingBackendUserAuthentication->checkAuthMode()
. - Instances calling
BackendUserAuthentication->checkAuthMode()
with four instead of three arguments. The extension scanner will find usages as weak match. - Instances using
authMode_enforce
for'type' => 'select'
fields.
Migration¶
The majority of instances does not need to take care of anything. The values of the database
field 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.
Accessing explicitADmode¶
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'
.
Using authMode_enforce='strict'¶
Extensions with select fields using authMode
previously had different handling
if authMode_enforce => 'strict'
has been set: Let's say an editor accesses a record
with an authMode
field being set to a value it has no access to. With authMode_enforce
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" (explicit_allowdeny
) field.
Using authMode='explicitDeny'¶
The "deny list" approach for single field values has been removed, the only allowed option
for authMode
is explicitAllow
. Extensions using config value explicitDeny
should be adapted to switch to explicitAllow
instead. The upgrade wizard
"Migrate backend groups "explicit_allowdeny" field to simplified format." that transfers
existing be_groups
rows to the new format drops any DENY
fields and instructs
admins no set new access rights of affected backend groups.
Using authMode='individual'¶
Handling of 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.