Files
cms-core/Documentation/Changelog/12.0/Breaking-97265-SimplifiedAccessModeSystem.rst
T

118 lines
5.5 KiB
ReStructuredText

.. include:: /Includes.rst.txt
.. _breaking-97265:
================================================
Breaking: #97265 - Simplified access mode system
================================================
See :issue:`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 :php:`TYPO3_CONF_VARS['BE']['explicitADmode']`
has been removed and is not evaluated anymore.
* The only valid value for TCA config option :php:`authMode` on :php:`'type' => 'select'`
fields is now :php:`explicitAllow`. The values :php:`explicitDeny` and :php:`individual`
are invalid and no longer evaluated.
* With removal of :php:`authMode' => 'individual'` for TCA select fields, the sixth
:php:`items` option is obsolete and removed. The values :php:`EXPL_ALLOW` and
:php:`EXPL_DENY` are without any effect.
* Handling of TCA config option :php:`authMode_enforce` has been removed.
* The fourth tuple of :sql:`be_groups` field :sql:`explicit_allowdeny` that was
previously set to either :sql:`ALLOW` or :sql:`DENY` is removed.
* The fourth argument on :php:`BackendUserAuthentication->checkAuthMode()` has
been removed.
Impact
======
Using any of the above removed options will trigger a PHP :php:`E_USER_DEPRECATED` error.
Using :php:`explicitDeny` and :php:`individual` as value for TCA config option
:php:`authMode` is no longer supported by the system and may need manual
adaptions. Accessing :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']`
may lead to a PHP warning level error.
Affected Installations
======================
* Instances with extensions using :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']`.
The extension scanner will typically find affected instances.
* Instances with TCA select fields using :php:`'authMode' => 'explicitDeny'`.
* Instances with TCA select fields using :php:`'authMode' => 'individual'` and select
items being set to :php:`EXPL_ALLOW` or :php:`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 :sql:`explicit_allowdeny` of table :sql:`be_groups`
may be affected if they expect the fourth field being set to :sql:`ALLOW` or :sql:`DENY`.
This is unlikely since the Core provides an API for this field using
:php:`BackendUserAuthentication->checkAuthMode()`.
* Instances calling :php:`BackendUserAuthentication->checkAuthMode()` with four instead of
three arguments. The extension scanner will find usages as weak match.
* Instances using :php:`authMode_enforce` for :php:`'type' => 'select'` fields.
Migration
=========
The majority of instances does not need to take care of anything. The values of the database
field :sql:`explicit_allowdeny` for table :sql:`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 :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']` has been changed as
if it is always set to :php:`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: :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode'] ?? 'explicitAllow'`.
Using authMode_enforce='strict'
-------------------------------
Extensions with select fields using :php:`authMode` previously had different handling
if :php:`authMode_enforce => 'strict'` has been set: Let's say an editor accesses a record
with an :php:`authMode` field being set to a value it has no access to. With :php:`authMode_enforce`
*not* being set to :php:`strict`, the editor was still able to edit the record and set the value
to something it had access to. With :php:`authMode_enforce` being set to :php:`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" (:sql:`explicit_allowdeny`) field.
Using authMode='explicitDeny'
-----------------------------
The "deny list" approach for single field values has been removed, the only allowed option
for :php:`authMode` is :php:`explicitAllow`. Extensions using config value :php:`explicitDeny`
should be adapted to switch to :php:`explicitAllow` instead. The upgrade wizard
"Migrate backend groups "explicit_allowdeny" field to simplified format." that transfers
existing :sql:`be_groups` rows to the new format *drops* any :sql:`DENY` fields and instructs
admins to set new access rights of affected backend groups.
Using authMode='individual'
---------------------------
Handling of :php:`authMode` being set to :php:`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.
.. index:: Backend, Database, LocalConfiguration, PHP-API, TCA, PartiallyScanned, ext:core