.. 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