[!!!][TASK] Stateless FileNameValidator

[TYPO3IncTeam]

ℹ️ View this commit on Github
👥 Authored by Christian Kuhn lolli@schwarzbu.ch
✔️ Merged by Stefan Bürk stefan@buerk.tech

Commit message

[!!!][TASK] Stateless FileNameValidator

There is very little reason to instantiate
ext:core FileNameValidator with a custom
regex. The core does not have a single place
that uses this. The 'manual' constructor can
be removed without much trouble, making the
service stateless and easily injectable.

Resolves: #105733
Releases: main
Change-Id: I8e827ff15afd1c756c502b9952fd6d0f8aaa68bf
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/87297
Tested-by: Stefan Bürk stefan@buerk.tech
Reviewed-by: Stefan Bürk stefan@buerk.tech
Reviewed-by: Anja Leichsenring aleichsenring@ab-softlab.de
Tested-by: core-ci typo3@b13.com
Tested-by: Anja Leichsenring aleichsenring@ab-softlab.de

➕ Added files

14.0/Breaking-105733-FileNameValidatorNoLongerAcceptsCustomRegexIn__construct.rst

..  include:: /Includes.rst.txt

..  _breaking-105733-1733018161:

=====================================================================================
Breaking: #105733 - FileNameValidator no longer accepts custom regex in __construct()
=====================================================================================

See :issue:`105733`

Description
===========

Class :php:`TYPO3\CMS\Core\Resource\Security\FileNameValidator` does not handle
a custom file deny pattern in :php:`__construct()` anymore. The service is now
stateless and can be injected without side effects.


Impact
======

A custom partial regex as first constructor argument when instantiating the
service is ignored. The service relies on :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['fileDenyPattern']`
configuration, and a hard coded constant as fallback.


Affected installations
======================

Instances with custom extensions using
:php:`GeneralUtility::makeInstance(FileNameValidator::class, 'some-custom-pattern');`
are affected. This is most likely a very rare case.


Migration
=========

Extensions that need to test with custom patterns that can not be declared
globally using :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['fileDenyPattern']`
should probably switch to an own service implementing the test, or inline
the code. The main worker code of the service is just four lines of code.

..  index:: PHP-API, NotScanned, ext:core