Project

General

Profile

Actions

Bug #92908

closed

Using EXT: in allowedExtensionPaths causes exception with 10.4.10

Added by Stefan Hekele about 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Form Framework
Target version:
-
Start date:
2020-11-23
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:

Description

FormEngineSetup.yaml:

TYPO3:
  CMS:
    Form:
      persistenceManager:
        allowedExtensionPaths:
          10: 'EXT:my_form/Resources/Private/Forms/'
        allowSaveToExtensionPaths: false
        allowDeleteFromExtensionPaths: false

This worked up to and including 10.4.9.

However, upon installing 10.4.10, the frontend now instead displays the following exception upon loading a page with a predefined form:

(1/1) #1314516810 TYPO3\CMS\Core\Resource\Exception\FolderDoesNotExistException
Folder "/my_form/Resources/Private/Forms/" does not exist.

I traced the relevant change back to /typo3/sysext/core/Classes/Resource/ResourceFactory.php::getFolderObjectFromCombinedIdentifier()

At line 504, what used to be

$storageUid = $parts[0];
has been changed to
$storageUid = (int)$parts[0];
in commit https://github.com/TYPO3/TYPO3.CMS/commit/a79c665c9abe112fbdf8f8a45ce734b6030a0606

This causes the EXT part of the config to be cast to 0, meaning that the is_numeric() in TYPO3\CMS\Core\Resource\ResourceFactory::getStorageObject() is no longer throwing an Exception - which itself was caught by TYPO3\CMS\Form\Mvc\Property\PropertyMappingConfiguration::checkSaveFileMountAccess() -, and instead the path is resolved and checked against storage uid 0, where it naturally can't be found.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Task #92264: Fix phpstan checkFunctionArgumentTypes errors in ext:core ResourceClosed2020-09-10

Actions
Actions

Also available in: Atom PDF