TYPO3 v15 dev-main snapshot ()
This commit is contained in:
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-92628:
|
||||
|
||||
=================================================
|
||||
Deprecation: #92628 - Login Logo without Alt-Text
|
||||
=================================================
|
||||
|
||||
See :issue:`92628`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The configuration of the extension "backend" has now the possibility to
|
||||
provide an alt-text for a custom login logo.
|
||||
|
||||
As an alt-text is needed for accessibility reasons, not setting an alt-text has been marked as
|
||||
deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Not configuring an alt-text will trigger a PHP :php:`E_USER_DEPRECATED` error.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All instances that have defined a custom login logo are affected.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Configure an alt-text for your custom login logo.
|
||||
|
||||
.. index:: Backend, NotScanned, ext:backend
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93149:
|
||||
|
||||
==============================================================================
|
||||
Deprecation: #93149 - T3Editor JavaScript module replaced by CodeMirrorElement
|
||||
==============================================================================
|
||||
|
||||
See :issue:`93149`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The T3Editor - that offers code editing capabilities for TCA
|
||||
:php:`renderType=t3editor` fields - has been refactored into a custom HTML
|
||||
element :html:`<typo3-t3editor-codemirror>`.
|
||||
The element is provided by the new JavaScript module
|
||||
js:`TYPO3/CMS/T3editor/Element/CodeMirrorElement`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Using :html:`<textarea class="t3editor">..</textarea>` will work as before.
|
||||
The new custom element will automatically be used, but a deprecating warning
|
||||
will be logged to the browser console.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
TYPO3 installations that use the T3Editor library in custom extensions, which
|
||||
is very unlikely.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Use the new :js:`TYPO3/CMS/T3editor/Element/CodeMirrorElement` module and adapt
|
||||
your markup to read:
|
||||
|
||||
.. code-block:: html
|
||||
|
||||
<typo3-t3editor-codemirror mode="..." addons="[..]" options="{..}">
|
||||
<textarea name="foo">..</textarea>
|
||||
</typo3-t3editor-codemirror>
|
||||
|
||||
Please make sure to drop the t3editor class from the textarea.
|
||||
|
||||
.. index:: Backend, JavaScript, NotScanned, ext:backend
|
||||
@@ -0,0 +1,37 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93454:
|
||||
|
||||
===================================================
|
||||
Deprecation: #93454 - Rename Sortable to sortablejs
|
||||
===================================================
|
||||
|
||||
See :issue:`93454`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Due to importing TypeScript declarations of SortableJS, it's required to make
|
||||
the library available as :js:`sortablejs`. The previously used name :js:`Sortable` is
|
||||
still available, but has been marked as deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
There is no direct impact, as we cannot intercept loading the module to log a
|
||||
deprecation message.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
Every 3rd party extension using :js:`SortableJS` is affected.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Change the import of the library to :js:`sortablejs`.
|
||||
|
||||
.. index:: JavaScript, NotScanned, ext:backend
|
||||
@@ -0,0 +1,39 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _deprecation-93506:
|
||||
|
||||
========================================
|
||||
Deprecation: #93506 - jQuery in tooltips
|
||||
========================================
|
||||
|
||||
See :issue:`93506`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Passing jQuery objects to the methods :js:`show()` and :js:`hide()` of the
|
||||
module :file:`TYPO3/CMS/Backend/Tooltip` has been marked as deprecated.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Passing jQuery objects to the aforementioned methods will log a deprecation message in
|
||||
the browser's console.
|
||||
|
||||
|
||||
Affected Installations
|
||||
======================
|
||||
|
||||
All 3rd party extensions passing jQuery objects to either :js:`show()` or
|
||||
:js:`hide()` are affected.
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Either pass a single :js:`HTMLElement` (e.g. from
|
||||
:js:`document.querySelector('#my-element')`) or a :js:`NodeList` (e.g. from
|
||||
:js:`document.querySelectorAll('.my-element')`) to :js:`show()` or :js:`hide()`.
|
||||
|
||||
.. index:: Backend, JavaScript, NotScanned, ext:backend
|
||||
@@ -0,0 +1,47 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-78036:
|
||||
|
||||
===========================================================
|
||||
Feature: #78036 - Synchronize folder relations after rename
|
||||
===========================================================
|
||||
|
||||
See :issue:`78036`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
TYPO3 features the File module where editors and integrators can manage
|
||||
all their media assets in a structured way. Certainly, one essential
|
||||
task is to rename folders from time to time. Since folders are sometimes
|
||||
referenced in other records, e.g. file collections or file mounts, these
|
||||
relations did previously break after a folder was renamed, because the
|
||||
reference index does not contain these relations.
|
||||
|
||||
Therefore, TYPO3 does now automatically synchronize all references of
|
||||
a folder when it is renamed. This is done by registering event listeners
|
||||
for the :php:`AfterFolderRenamedEvent` event. This event is dispatched as
|
||||
soon as a folder was successfully renamed.
|
||||
|
||||
To be able to automatically replace the old folder name with the new one,
|
||||
the mentioned event is extended for another property :php:`$sourceFolder`.
|
||||
This property can be retrieved using the public :php:`getSourceFolder()`
|
||||
method.
|
||||
|
||||
Note that the synchronization is always performed, as soon as a folder
|
||||
was renamed. This does not only apply to the File module, but for every
|
||||
:php:`ResourceFactory->renameFolder()` call, since the event is being
|
||||
dispatched in this method.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
All :sql:`sys_filemounts` and :sql:`sys_file_collection` records which
|
||||
reference a renamed folder are now automatically synchronized.
|
||||
|
||||
The :php:`AfterFolderRenamedEvent` event now features a new property
|
||||
:php:`$sourceFolder`. Extension authors can use this event to add
|
||||
further synchronization for their custom records.
|
||||
|
||||
.. index:: Backend, FAL, ext:core
|
||||
@@ -0,0 +1,38 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-78760:
|
||||
|
||||
================================================
|
||||
Feature: #78760 - Resizable Navigation Component
|
||||
================================================
|
||||
|
||||
See :issue:`78760`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The Navigation Component in TYPO3's backend, which shows e.g.
|
||||
the Page Tree or the folder tree (within the file list module),
|
||||
can be resized via Drag&Drop or via a button, which is layered
|
||||
within the Navigation Component itself. A similar functionality
|
||||
was previously put in the top bar on the left, for mobile devices,
|
||||
but was removed in favor of this new solution.
|
||||
|
||||
The size of the navigation component is now stored in the users'
|
||||
"uc" configuration to be persistent during various logins and
|
||||
kept for multiple sessions.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
TYPO3 now allows to not just resize the pagetree component,
|
||||
but any navigation component (just like iframes).
|
||||
|
||||
When the component is collapsed, an icon is shown to indicate that
|
||||
the navigation can be re-opened.
|
||||
|
||||
This makes it easier for editors to have a distraction-free
|
||||
management interface when needed.
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
@@ -0,0 +1,71 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-89509:
|
||||
|
||||
=========================================================
|
||||
Feature: #89509 - Data Processor to resolve FlexForm data
|
||||
=========================================================
|
||||
|
||||
See :issue:`89509`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
TYPO3 offers "FlexForms", which can be used to store data within an XML
|
||||
structure inside a single DB column. Since this information could also be
|
||||
relevant in the view, a new data processor
|
||||
:php:`TYPO3\CMS\Frontend\DataProcessing\FlexFormProcessor` is added. It
|
||||
converts the FlexForm data of a given field into a Fluid readable array.
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
:`fieldName`: Field name of the column the FlexForm data is stored in (default: :sql:`pi_flexform`).
|
||||
:`as`: The variable to be used within the result (default: :php:`flexFormData`).
|
||||
|
||||
Example of a minimal TypoScript configuration
|
||||
---------------------------------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
10 = TYPO3\CMS\Frontend\DataProcessing\FlexFormProcessor
|
||||
|
||||
The converted array can be accessed within the Fluid template
|
||||
with the :html:`{flexFormData}` variable.
|
||||
|
||||
Example of an advanced TypoScript configuration
|
||||
-----------------------------------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
10 = TYPO3\CMS\Frontend\DataProcessing\FlexFormProcessor
|
||||
10 {
|
||||
fieldName = my_flexform_field
|
||||
as = myOutputVariable
|
||||
}
|
||||
|
||||
The converted array can be accessed within the Fluid template
|
||||
with the :html:`{myOutputVariable}` variable.
|
||||
|
||||
Example with a custom sub processor
|
||||
------------------------------------
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
10 = TYPO3\CMS\Frontend\DataProcessing\FlexFormProcessor
|
||||
10 {
|
||||
fieldName = my_flexform_field
|
||||
as = myOutputVariable
|
||||
dataProcessing {
|
||||
10 = Vendor\MyExtension\DataProcessing\CustomFlexFormProcessor
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
It's now possible to access the FlexForm data of a field in a
|
||||
readable way in the Fluid template.
|
||||
|
||||
.. index:: Fluid, TypoScript, Frontend
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-92338:
|
||||
|
||||
================================================================
|
||||
Feature: #92338 - Allow link text wrapping in TypolinkViewhelper
|
||||
================================================================
|
||||
|
||||
See :issue:`92338`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Using the :html:`f:link.typolink` ViewHelper for generating links to internal
|
||||
pages does now allow to wrap the automatically rendered link title, which
|
||||
is usually the page title of the target page.
|
||||
|
||||
Therefore a new argument :html:`textWrap` is available, which can be used to
|
||||
define the :typoscript:`wrap` setting for the typolink.
|
||||
|
||||
Defining :html:`<f:link.typolink parameter="123" textWrap="<span>|</span>"/>`
|
||||
will generate :html:`<a href="some/site"><span>My page title</span></a>`.
|
||||
|
||||
.. note::
|
||||
|
||||
When adding additional classes to the :html:`textWrap`, ensure quotes are correctly
|
||||
escaped: :html:`<f:link.typolink parameter="123" textWrap="<span class=\"my-class\">|</span>"/>`.
|
||||
|
||||
If :html:`textWrap` is set, the typolink option :php:`ATagBeforeWrap` is automatically
|
||||
enabled, because the :typoscript:`wrap` should only be applied to the link text. Every
|
||||
other use case can be handled in the fluid template itself.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
It's now possible with the :html:`f:link.typolink` ViewHelper, to wrap the
|
||||
automatically generated link text, e.g. when linking to an internal page.
|
||||
|
||||
.. index:: Fluid, ext:fluid
|
||||
@@ -0,0 +1,27 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-92628:
|
||||
|
||||
============================================
|
||||
Feature: #92628 - Add Alt-Text To Login Logo
|
||||
============================================
|
||||
|
||||
See :issue:`92628`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The configuration of the extension "backend" has now the possibility to
|
||||
provide an alt-text for a custom login logo.
|
||||
|
||||
In the module "Admin tools > Settings" go to card "Extension Configuration"
|
||||
and open the dialog. Select extension "backend" and fill in the field
|
||||
"Logo Alt-Text" on the "Login" tab. You can also set :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTENSIONS']['backend']['loginLogoAlt']`.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Setting the alt-text enhances the accessibility of the login page.
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-92704:
|
||||
|
||||
==============================================================
|
||||
Feature: #92704 - Improve keyboard navigation for module menus
|
||||
==============================================================
|
||||
|
||||
See :issue:`92704`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The module menu implements the keyboard navigation suggested
|
||||
by the ARIA Best Practices 1.1 for roles :html:`menubar` and :html:`menu`.
|
||||
The first level menu has a :html:`menubar` role, the second level
|
||||
submenus have a :html:`menu` role. The buttons have the :html:`menuitem`
|
||||
role. Both the :html:`menubar` and the :html:`menu` are oriented
|
||||
vertically for assistive technology matching the visual
|
||||
representation which affects the keyboard navigation.
|
||||
|
||||
Space/Enter shows the module unless the item has a submenu.
|
||||
Space/Enter and Right Arrow open a submenu and move focus to
|
||||
the first item.
|
||||
|
||||
Up/Down Arrow and Home/End navigate within the current
|
||||
level of the menu.
|
||||
Ctrl + Home/End navigate within the first level of the menu
|
||||
(extension of the ARIA pattern).
|
||||
|
||||
Left/Right Arrow moves to the parent items predecessor/successor
|
||||
when on a submodule item. The submenu will not be closed
|
||||
(deviation from the ARIA pattern).
|
||||
|
||||
Escape moves to the parent item of a submodule item.
|
||||
The submenu will not be closed (deviation from the ARIA pattern).
|
||||
|
||||
Tab and Shift + Tab move to the next item outside of the
|
||||
module menu.
|
||||
|
||||
The help menu implements the keyboard navigation suggested
|
||||
by the ARIA Best Practices 1.1 for the role :html:`menu`. This
|
||||
is the same as the module menu but limited to a single level.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The main module menu and the help menu are now usable with keyboard alone.
|
||||
This includes users that access the backend with a screen reader or other
|
||||
assistive technology.
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-92942:
|
||||
|
||||
=========================================================================
|
||||
Feature: #92942 - Allow icon overlay for newContentElementWizard elements
|
||||
=========================================================================
|
||||
|
||||
See :issue:`92942`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The new Content Element wizard within the page module now allows
|
||||
to define an icon overlay for each wizard element using the new
|
||||
TSconfig option :typoscript:`iconOverlay` next to a defined :typoscript:`iconIdentifier`.
|
||||
|
||||
This is especially useful for custom content elements that use the
|
||||
same :typoscript:`iconIdentifier` several times, but still have to be differentiated.
|
||||
|
||||
The full configuration path is
|
||||
:typoscript:`mod.wizards.newContentElement.wizardItems.*.elements.*.iconOverlay`.
|
||||
|
||||
An example configuration could look like this:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
mod.wizards.newContentElement.wizardItems {
|
||||
common.elements {
|
||||
my_element {
|
||||
iconIdentifier = content-my-icon
|
||||
iconOverlay = content-my-icon-overlay
|
||||
title = LLL:EXT:my_extension/Resources/Private/Language/ContentTypes.xlf:my_element_title
|
||||
description = LLL:EXT:my_extension/Resources/Private/Language/ContentTypes.xlf:my_element_description
|
||||
tt_content_defValues {
|
||||
CType = my_element
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
It's now possible to define an :html:`iconOverlay` next to an :html:`iconIdentifier`
|
||||
for newContentElementWizard elements.
|
||||
|
||||
.. index:: Backend, TSConfig, ext:backend
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93117:
|
||||
|
||||
================================================================
|
||||
Feature: #93117 - Add reset button to Backend User module filter
|
||||
================================================================
|
||||
|
||||
See :issue:`93117`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The backend user module provides a filter functionality with a
|
||||
couple of options to filter for. The filter state (selected options)
|
||||
is also saved in the backend user settings, which means,
|
||||
the filter state will remain after switching to another module.
|
||||
|
||||
Since there are a lot of filter options which previously had to be
|
||||
reset one by one, a new reset button is now introduced. This button
|
||||
allows to reset the whole filter at once.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
It's now possible to reset the whole backend user module filter
|
||||
at once, using the new reset button.
|
||||
|
||||
.. index:: Backend, ext:beuser
|
||||
@@ -0,0 +1,71 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93174:
|
||||
|
||||
===========================================
|
||||
Feature: #93174 - Lazy console command list
|
||||
===========================================
|
||||
|
||||
See :issue:`93174`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The TYPO3 command line utility :bash:`typo3/sysext/core/bin/typo3` has been adapted to
|
||||
avoid instantiating all available console commands during the execution of the
|
||||
default :bash:`typo3 list` command.
|
||||
|
||||
This enables commands to inject dependencies that require a fully booted system,
|
||||
or a database connection, without causing the console command list to break or
|
||||
slow down.
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
New tag properties for the :yaml:`console.command` dependency injection tag
|
||||
have been added. The properties control the appearance of console commands in the
|
||||
list output.
|
||||
|
||||
:`description`: The description of the command (default: `''`).
|
||||
:`hidden`: Command will be hidden from `list` if `true` (default: `false`).
|
||||
|
||||
Example of a command registration that includes a description
|
||||
-------------------------------------------------------------
|
||||
|
||||
The command list requires the description to be set next to the command
|
||||
name in :file:`Services.yaml` in order for descriptions to be shown:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# Configuration/Services.yaml
|
||||
services:
|
||||
My\Namespace\Command\ExampleCommand:
|
||||
tags:
|
||||
- name: 'console.command'
|
||||
command: 'my:example'
|
||||
description: 'An example command that demonstrates some stuff'
|
||||
# not required, defaults to false
|
||||
hidden: false
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
Extension authors should add the :yaml:`description` property to existing
|
||||
:yaml:`console.command` dependency injection tags.
|
||||
The call to :php:`$this->setDescription()` in :php:`Command::configure()` should
|
||||
be removed, as the description, as defined in :file:`Services.yaml`, will be
|
||||
injected into the command.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Extensions authors are now able to inject arbitrary dependencies in console
|
||||
commands, without impacting the loading of the command list.
|
||||
|
||||
Integrators profit from a stable command list that is fast and always available,
|
||||
even if a command is not instantiable or if it inadvertently contains too much
|
||||
logic inside the command constructor.
|
||||
|
||||
.. index:: CLI, ext:core
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93426:
|
||||
|
||||
==================================================================
|
||||
Feature: #93426 - SVG-based Tree for Folder Navigation with Filter
|
||||
==================================================================
|
||||
|
||||
See :issue:`93426`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The "File" module area (with the "File List" module) has a completely
|
||||
rewritten Navigation Component called :html:`FileStorageTree`.
|
||||
|
||||
This Navigation Component is based on the same functionality
|
||||
as the Page Tree - a SVG-based tree - and also offers lazy loading
|
||||
of multiple nesting levels.
|
||||
|
||||
The previous implementation was based on an iframe with much
|
||||
effort to load pure HTML instead of using SVGs. Since the file list component
|
||||
was the last occurrence of using the iframe technology for Navigation
|
||||
Components, this functionality will be marked as deprecated in later TYPO3 v11 releases.
|
||||
|
||||
The main benefit of the Folder Navigation based on the SVG tree is the enhanced
|
||||
loading functionality. This way, the Folder Navigation has the exact same
|
||||
look&feel as the Page Tree, and also now contains an always-enabled filter
|
||||
on top of the Component, just as the Page Tree Navigation Component.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
The navigation state of the component is stored similarly
|
||||
to the Page Tree as both components benefit from sharing code.
|
||||
|
||||
The filter inside the Folder Navigation allows to search
|
||||
for a folder or storage name, and even file names (no search through meta-data).
|
||||
Users can filter for e.g. ".pdf" to show all available folders where
|
||||
PDF files are stored.
|
||||
|
||||
Extension Authors who want to use a file-related navigation component in
|
||||
their own extension can do this by specifying the :php:`navigationComponentId`
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addModule(
|
||||
'random',
|
||||
'filerelatedmodule',
|
||||
'top',
|
||||
null,
|
||||
[
|
||||
'navigationComponentId' => 'TYPO3/CMS/Backend/Tree/FileStorageTreeContainer',
|
||||
'routeTarget' => \MyVendor\MyExtension\Controller\FileRelatedController::class . '::indexAction',
|
||||
'access' => 'user,group',
|
||||
'name' => 'myext_file',
|
||||
'icon' => 'EXT:myextension/Resources/Public/Icons/module-file-related.svg',
|
||||
'labels' => 'LLL:EXT:myextension/Resources/Private/Language/Modules/file_related.xlf'
|
||||
]
|
||||
);
|
||||
|
||||
.. index:: Backend, ext:backend
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93455:
|
||||
|
||||
=====================================================================
|
||||
Feature: #93455 - Backend Routes restricted to specified HTTP methods
|
||||
=====================================================================
|
||||
|
||||
See :issue:`93455`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
Individual Backend Routes in TYPO3 Backend can now be configured
|
||||
to only apply for specific HTTP methods (e.g. GET or POST).
|
||||
|
||||
This way, custom Backend routes can be limited to only allow
|
||||
submitted form content to be delivered via HTTP POST for example.
|
||||
|
||||
The underlying symfony routing component, which is already used
|
||||
in TYPO3 Backend for routing through the proper API, is handling the
|
||||
restriction to the HTTP method / verb automatically.
|
||||
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Any Backend route, configured in extensions via
|
||||
:file:`EXT:my_extension/Configuration/Backend/Routes.php`
|
||||
and :file:`EXT:my_extension/Configuration/Backend/AjaxRoutes.php`
|
||||
has a new, optional property :php:`methods`, which expects an array
|
||||
to set one or more HTTP verbs, such as :html:`GET`, :html:`POST`, :html:`PUT` or :html:`DELETE`.
|
||||
|
||||
If no property is given, no restriction to a HTTP method is set.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
return [
|
||||
'my_route' => [
|
||||
'path' => '/benni/my-route',
|
||||
'methods' => ['POST'],
|
||||
'target' => MyVendor\MyPackage\Controller\MyRouteController::class . '::submitAction'
|
||||
]
|
||||
];
|
||||
|
||||
.. index:: Backend, PHP-API, ext:backend
|
||||
@@ -0,0 +1,281 @@
|
||||
|
||||
.. include:: /Includes.rst.txt
|
||||
|
||||
.. _feature-93526:
|
||||
|
||||
=============================================
|
||||
Feature: #93526 - Multi-Factor Authentication
|
||||
=============================================
|
||||
|
||||
See :issue:`93526`
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
TYPO3 is now capable of authentication via multiple factors, in short
|
||||
"multi-factor authentication" or "MFA". This is sometimes also referred to
|
||||
"2FA" as a 2-Factor Authentication process, where - in order to log in - the
|
||||
user needs
|
||||
|
||||
1) "something you know" (= the password) and
|
||||
2) "something you own" (= an authenticator device, or an authenticator app
|
||||
on mobile phones or desktop devices).
|
||||
|
||||
Read more about the concepts of `MFA on Wikipedia <https://en.wikipedia.org/wiki/Multi-factor_authentication>`_.
|
||||
|
||||
TYPO3 ships with some built-in MFA providers by default. But more importantly,
|
||||
TYPO3 now provides an API to allow extension authors to integrate their own
|
||||
MFA providers.
|
||||
|
||||
The API is designed in a way to allow providers to be used for TYPO3 Backend
|
||||
Authentication or Frontend Authentication with a multi-factor step in-between.
|
||||
|
||||
TYPO3 Core currently provides the integration for the TYPO3 Backend, but will
|
||||
fully support multi-factor authentication for the Frontend in future releases.
|
||||
|
||||
Impact
|
||||
======
|
||||
|
||||
Managing MFA providers is currently accessible via the User Settings module in
|
||||
the new tab called "Account security", which was previously called just
|
||||
"Password". The Account security tab displays the current state, if MFA can
|
||||
be configured or is already activated.
|
||||
|
||||
By default, the new field is displayed for every backend user. It is possible to
|
||||
disable it for specific users via userTSconfig:
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
setup.fields.mfaProviders.disabled = 1
|
||||
|
||||
Included MFA providers
|
||||
----------------------
|
||||
|
||||
TYPO3 Core includes two MFA providers:
|
||||
|
||||
1. Time-based one-time password (TOTP)
|
||||
|
||||
The most common MFA implementation. A QR-code is scanned (or alternatively,
|
||||
a shared secret can be entered) to connect an Authenticator app such as Google
|
||||
Authenticator, Microsoft Authenticator, 1Password, Authly or others to the
|
||||
system and then synchronize a token, which changes every 30 seconds.
|
||||
|
||||
On each log-in, after successfully entering the password, the six-digit code
|
||||
shown by the Authenticator App must be entered.
|
||||
|
||||
2. Recovery codes
|
||||
|
||||
This is a special provider which can only be activated if at least one other
|
||||
provider is active, as it's only meant as a fallback provider, in case the
|
||||
authentication credentials for the "main" provider(s) are lost. It is encouraged
|
||||
to activate this provider, and keep the codes at a safe place.
|
||||
|
||||
Setting up MFA for a backend user
|
||||
---------------------------------
|
||||
|
||||
Each provider is displayed with its icon, the name and a short description in
|
||||
the MFA configuration module. In case a provider is active this is indicated by
|
||||
a corresponding label, next to the providers' title. The same goes for a locked
|
||||
provider - an active provider, which can currently not be used since the
|
||||
provider specific implementation detected some unusual behaviour, e.g. to many
|
||||
false authentication attempts. Furthermore does the configured default provider
|
||||
indicate this state with a "star" icon, next to the providers title.
|
||||
|
||||
Each inactive provider contains a "Setup" button which opens the corresponding
|
||||
configuration view. This view can be different depending on the MFA provider.
|
||||
|
||||
Each active provider contains an "Edit / Change" button, which allows to adjust
|
||||
the providers' settings. This view allows for example to set a provider as the
|
||||
default (primary) provider, to be used on authentication. Note that the
|
||||
default provider setting will be automatically applied on activation of the
|
||||
first provider or in case it is the recommended provider for this user.
|
||||
|
||||
In case the provider is locked, the "Edit / Change" button changes its button
|
||||
title to "Unlock". This button can therefore be used to unlock the provider.
|
||||
This, depending on the provider to unlock, may require further actions by the
|
||||
user.
|
||||
|
||||
The "Deactivate" button can be used to deactivate the provider. This will,
|
||||
depending on the provider, usually also completely remove all provider specific
|
||||
settings.
|
||||
|
||||
Another view is the "Authentication view", which is displayed as soon as a user
|
||||
with at least one active provider has successfully passed the username and
|
||||
password mask.
|
||||
|
||||
As for the other views, it is up to the specific provider, used for the current
|
||||
multi-factor authentication attempt, what content is displayed in this view.
|
||||
In any case, if the user has further active providers, the view displays them
|
||||
as "Alternative providers" in the footer. So the user can switch between all
|
||||
activated providers on every authentication attempt.
|
||||
|
||||
All providers need to define a locking functionality. In case of the TOTP
|
||||
and recovery code providers, this e.g. includes an attempts count. Therefore,
|
||||
these providers are locked in case a wrong OTP was entered three times in a
|
||||
row. The attempts count is automatically reset as soon as a correct OTP is
|
||||
entered or the user unlocks the provider in the backend.
|
||||
|
||||
All Core providers also feature the "Last used" and "Last updated" information
|
||||
which can be retrieved in the "Edit / Change" view.
|
||||
|
||||
**Administration of users' MFA providers**
|
||||
|
||||
If a user is not able to access the backend anymore, e.g. because all of their
|
||||
active providers are locked, MFA needs to be disabled by an administrator for
|
||||
this specific user.
|
||||
|
||||
Administrators are able to manage users' MFA providers in the corresponding
|
||||
user record. The new `Multi-factor authentication` field displays a
|
||||
list of active providers and a button to deactivate MFA for the user, or
|
||||
only a specific MFA provider.
|
||||
|
||||
Note that all of these deactivate buttons are executed immediately, after
|
||||
confirming the appearing dialog, and can't be undone.
|
||||
|
||||
The backend users listing in the backend user module also displays whether MFA
|
||||
is enabled or currently locked, for each user. This allows an administrator a
|
||||
quick glance of the MFA usage of their users.
|
||||
|
||||
Via the System => Configuration admin module, it's possible to get an overview
|
||||
of all currently registered providers in the installation. This is especially
|
||||
helpful to find out the exact provider identifier, needed for some
|
||||
userTSconfig options.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
**Enforcing MFA for users**
|
||||
|
||||
It seems reasonable to require MFA for specific users or user groups. This can
|
||||
be achieved with :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['requireMfa']` which
|
||||
allows 5 options:
|
||||
|
||||
* `0`: Do not require multi-factor authentication (default)
|
||||
* `1`: Require multi-factor authentication for all users
|
||||
* `2`: Require multi-factor authentication only for non-admin users
|
||||
* `3`: Require multi-factor authentication only for admin users
|
||||
* `4`: Require multi-factor authentication only for system maintainers
|
||||
|
||||
To set this requirement only for a specific user or user group, a new
|
||||
userTSconfig option :typoscript:`auth.mfa.required` is introduced. The
|
||||
userTSconfig option overrules the global configuration.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
auth.mfa.required = 1
|
||||
|
||||
.. note::
|
||||
|
||||
As soon as MFA is required, the corresponding user is no longer able to
|
||||
access the backend, until at least one MFA provider is activated. After
|
||||
the users' primary authentication details (e.g. username+password) were
|
||||
successfully validated, a redirect to a dedicated endpoint is performed.
|
||||
On this endpoint, the user can choose and set up one of the available MFA
|
||||
providers. It's therefore also important for administrators to check if
|
||||
users, which are required to set up MFA, are allowed to choose at least
|
||||
one provider. Have a look at the next section about configuring "allowed
|
||||
providers".
|
||||
|
||||
**Allowed provider**
|
||||
|
||||
It is possible to only allow a subset of the available providers for some users
|
||||
or user groups.
|
||||
|
||||
A new configuration option "Allowed multi-factor authentication providers" is
|
||||
available in the user groups record in the "Access List" tab.
|
||||
|
||||
There may surely be use cases in which just a single provider should be
|
||||
disallowed for a specific user, which is however configured to be allowed in
|
||||
one of the assigned user groups. Therefore, the new userTSconfig option
|
||||
:typoscript:`auth.mfa.disableProviders` can be used. It overrules the
|
||||
configuration from the "Access List", which means if a provider is allowed in
|
||||
"Access List" but disallowed via userTSconfig, it will be disallowed for the
|
||||
user or user group the TSconfig applies to. This does not affect the remaining
|
||||
allowed providers from the "Access List".
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
auth.mfa.disableProviders := addToList(totp)
|
||||
|
||||
**Recommended provider**
|
||||
|
||||
To recommend a specific provider, :php:`$GLOBALS['TYPO3_CONF_VARS]['BE]['recommendedMfaProvider']`
|
||||
can be used and is set to :php:`totp` (Time-based one-time password) by default.
|
||||
|
||||
To set a recommended provider on a per user or user group basis, the new
|
||||
userTSconfig option :typoscript:`auth.mfa.recommendedProvider` can be used,
|
||||
which overrules the global configuration.
|
||||
|
||||
.. code-block:: typoscript
|
||||
|
||||
auth.mfa.recommendedProvider = totp
|
||||
|
||||
TYPO3 Integration and API
|
||||
-------------------------
|
||||
|
||||
.. important::
|
||||
|
||||
The MFA API is still experimental and subject to change until v11 LTS,
|
||||
since we are looking forward to receive feedback, especially for custom
|
||||
use-cases, the API is not capable yet.
|
||||
|
||||
To register a custom MFA provider, the provider class has to implement the new
|
||||
:php:`MfaProviderInterface`, shipped via a third-party extension. The provider
|
||||
then has to be configured in the extensions' :file:`Services.yaml` or
|
||||
:file:`Services.php` file with the :yaml:`mfa.provider` tag.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Vender\Extension\Authentication\Mfa\MyProvider:
|
||||
tags:
|
||||
- name: mfa.provider
|
||||
identifier: 'my-provider'
|
||||
title: 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:myProvider.title'
|
||||
description: 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:myProvider.description'
|
||||
setupInstructions: 'LLL:EXT:extension/Resources/Private/Language/locallang.xlf:myProvider.setupInstructions'
|
||||
icon: 'tx-extension-provider-icon'
|
||||
|
||||
This will register the provider `MyProvider` with the `my-provider` identifier.
|
||||
To change the position of your provider the :yaml:`before` and :yaml:`after`
|
||||
arguments can be useful. This can be needed if you e.g. like your provider to
|
||||
show up prior to any other provider in the MFA configuration module. The
|
||||
ordering is also taken into account in the authentication step while logging
|
||||
in. Note that the user defined default provider will always take precedence.
|
||||
|
||||
If you don't want your provider to be selectable as a default provider, set the
|
||||
:yaml:`defaultProviderAllowed` argument to `false`.
|
||||
|
||||
You can also completely deactivate existing providers with:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
TYPO3\CMS\Core\Authentication\Mfa\Provider\TotpProvider: ~
|
||||
|
||||
The :php:`MfaProviderInterface` contains a lot of methods to be implemented by
|
||||
the providers. This can be split up into state-providing ones,
|
||||
e.g. :php:`isActive` or :php:`isLocked` and functional ones,
|
||||
e.g. :php:`activate` or :php:`update`.
|
||||
|
||||
Their exact task is explained in the corresponding PHPDoc of the Interface files
|
||||
and the Core MFA provider implementations.
|
||||
|
||||
All of these methods are receiving either the current PSR-7 Request object, the
|
||||
:php:`MfaProviderPropertyManager` or both. The :php:`MfaProviderPropertyManager`
|
||||
can be used to retrieve and update the provider specific properties and
|
||||
also contains the :php:`getUser` method, providing the current user object.
|
||||
|
||||
To store provider specific data, the MFA API uses a new database field
|
||||
:sql:`mfa`, which can be freely used by the providers. The field contains a
|
||||
JSON encoded Array with each provider as array key. Common properties of such
|
||||
provider array could be `active` or `lastUsed`. Since the information is stored
|
||||
in either the :sql:`be_users` or the :sql:`fe_users` table, the context is
|
||||
implicit. Same goes for the user the providers deal with. It is important to
|
||||
have such a generic field so providers are able to store arbitrary data TYPO3
|
||||
does not need to know about.
|
||||
|
||||
To retrieve and update the providers data, the already mentioned
|
||||
:php:`MfaProviderPropertyManager`, which is automatically passed to all
|
||||
necessary provider methods, should be used. It is highly discouraged
|
||||
to directly access the :sql:`mfa` database field.
|
||||
|
||||
.. index:: Backend, Frontend, PHP-API, ext:core
|
||||
@@ -0,0 +1,42 @@
|
||||
:template: changelogOverview.html
|
||||
.. include:: /Includes.rst.txt
|
||||
.. _changelog-11-1:
|
||||
|
||||
11.1 Changes
|
||||
=============
|
||||
|
||||
**Table of contents**
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
Breaking Changes
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
None since TYPO3 v11.0 release.
|
||||
|
||||
.. attention::
|
||||
|
||||
After TYPO3 v11.0, only new functionality with a solid migration path can be added on top,
|
||||
with aiming for as little as possible breaking changes after the initial v11.0 release on the way to LTS.
|
||||
|
||||
Features
|
||||
^^^^^^^^
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Feature-*
|
||||
|
||||
Deprecation
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
Deprecation-*
|
||||
Reference in New Issue
Block a user