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_
has been removed and is not evaluated anymore.CONF_ VARS ['BE'] ['explicit ADmode'] - The only valid value for TCA config option
auth
onMode 'type' => 'select'
fields is nowexplicit
. The valuesAllow explicit
andDeny individual
are invalid and no longer evaluated. - With removal of
auth
for TCA select fields, the sixthMode' => 'individual' items
option is obsolete and removed. The valuesEXPL_
andALLOW EXPL_
are without any effect.DENY - Handling of TCA config option
auth
has been removed.Mode_ enforce - The fourth tuple of
be_
fieldgroups explicit_
that was previously set to eitherallowdeny ALLOW
orDENY
is removed. - The fourth argument on
Backend
has been removed.User Authentication->check Auth Mode ()
Impact
Using any of the above removed options will trigger a PHP E_
error.
Using explicit
and individual
as value for TCA config option
auth
is no longer supported by the system and may need manual
adaptions. Accessing $GLOBALS
may lead to a PHP warning level error.
Affected Installations
- Instances with extensions using
$GLOBALS
. The extension scanner will typically find affected instances.['TYPO3_ CONF_ VARS'] ['BE'] ['explicit ADmode'] - Instances with TCA select fields using
'auth
.Mode' => 'explicit Deny' - Instances with TCA select fields using
'auth
and select items being set toMode' => 'individual' EXPL_
orALLOW EXPL_
. 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.DENY - Instances manually dealing with the
explicit_
of tableallowdeny be_
may be affected if they expect the fourth field being set togroups ALLOW
orDENY
. This is unlikely since the Core provides an API for this field usingBackend
.User Authentication->check Auth Mode () - Instances calling
Backend
with four instead of three arguments. The extension scanner will find usages as weak match.User Authentication->check Auth Mode () - Instances using
auth
forMode_ enforce 'type' => 'select'
fields.
Migration
The majority of instances does not need to take care of anything. The values of the database
field explicit_
for table be_
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
has been changed as
if it is always set to explicit
. 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
.
Using authMode_enforce='strict'
Extensions with select fields using auth
previously had different handling
if auth
has been set: Let's say an editor accesses a record
with an auth
field being set to a value it has no access to. With auth
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 auth
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_
) field.
Using authMode='explicitDeny'
The "deny list" approach for single field values has been removed, the only allowed option
for auth
is explicit
. Extensions using config value explicit
should be adapted to switch to explicit
instead. The upgrade wizard
"Migrate backend groups "explicit_allowdeny" field to simplified format." that transfers
existing be_
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 auth
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.