Bug #93797
closed
error while property mapping a FileReference in frontend
Added by Oliver Beck over 3 years ago.
Updated about 3 years ago.
Description
this problem exists since updating from 9.5.24 to 9.5.26. I have file uploads fields in fluid forms, for instance:
<f:form.upload property="logo" />
the property "logo" inside the model is of type FileReference (custom FileReference Class, which extends \TYPO3\CMS\Extbase\Domain\Model\FileReference).
That worked as expected when the form was submitted, with 9.5.26 I get this error
(1/2) #1297759968 TYPO3\CMS\Extbase\Property\Exception
Exception while property mapping at property path "logo": Property "name" was not found in target object of type "Vendor\PackageName\Domain\Model\FileReference".
see attachment for further details
Files
The same issue and error message happens since 10.4.14. I've downgraded to 10.4.13 and it works again.
Exception while property mapping at property path "image": Property "name" was not found in target object of type "TYPO3\CMS\Extbase\Domain\Model\FileReference".
We have this use case for f:form.upload with ObjectStorage<FileReference> and for formvh:form.uploadedResource. Both cases depend on Forms extension being active. This has worked since TYPO3 8 and now stopped working with the Security Fix in 10.4.14.
Can be easily reproduced:
- Activate Forms extension (Typoscript doesn't need to be loaded), so the FileReferenceConverter etc. is available
- Have a Model with $image / ObjectStorage<FileReference>
- Have an extension with f:form.upload using $image.NEW as the property value
- Try to upload ONE image (multiple still don't work reliably)
- Get the error message described
Hi, it seems like your extensions rely on the UploadedFileReferenceConverter
, which was, prior to the latest security release, globally available, while it was always only meant to be used inside EXT:form. Actually it's very likely that you used this converter unintentionally, just because it was configured with a high priority.
See https://typo3.org/security/advisory/typo3-core-sa-2021-002
Extbase extensions, who rely on the global availability of the UploadedFileReferenceConverter must now implement a custom TypeConverter to handle file uploads or explicitly implement the ext:form UploadedFileReferenceConverter with appropriate setting for accepted mime-types.
Therefore, like the advisory states, you have to implement your own TypeConverter for converting uploaded files to a FileReference object or otherwise explicitly implement the converter in your extensions.
In any case, please keep the security in mind and properly check the submitted files for their file extension and actual mime-type.
A question on the f:form.upload situation as a whole: If Fluid provides f:form.upload, wouldn't it be helpful to offer a working solution for that Viewhelper in general? It seems to me a very common use case to want to upload files through a form, that are then available as FAL objects. Or is it because of the structure of the core that this problem cannot be solved fully on an abstract/general level? I was happy when I noticed ext:form providing an easy way to make f:form.upload work with the core, as it's a very common use case that we have to implement and I like to use as much of the core as possible to have less problems when we have to update the systems.
Oliver Bartsch wrote in #note-2:
Hi, it seems like your extensions rely on the UploadedFileReferenceConverter
, which was, prior to the latest security release, globally available, while it was always only meant to be used inside EXT:form. Actually it's very likely that you used this converter unintentionally, just because it was configured with a high priority.
See https://typo3.org/security/advisory/typo3-core-sa-2021-002
Extbase extensions, who rely on the global availability of the UploadedFileReferenceConverter must now implement a custom TypeConverter to handle file uploads or explicitly implement the ext:form UploadedFileReferenceConverter with appropriate setting for accepted mime-types.
Therefore, like the advisory states, you have to implement your own TypeConverter for converting uploaded files to a FileReference object or otherwise explicitly implement the converter in your extensions.
In any case, please keep the security in mind and properly check the submitted files for their file extension and actual mime-type.
Hi namesake :-)
thank you for your advise, I'll try that out
Hey Oliver,
do you have any solution for this Problem?
Jakob Schillinger wrote in #note-5:
Hey Oliver,
do you have any solution for this Problem?
I had the same problem with my front-end file upload. I had created a custom type converter based on the Helmut Hummel upload example that was displaying the same behaviour as described. After much hair-pulling what worked for me was to specifically set the type converter in the controller function. Of all the examples I found none did this.
exampleController.php
protected function setTypeConverterConfigurationForImageUpload($argumentName)
{
...
$newFileConfiguration->forProperty('file')->setTypeConverter(
$this->objectManager->get('\Helhum\UploadExample\Property\TypeConverter\UploadedFileReferenceConverter')
);
...
}
I hope this helps.
I cannot emphasize enough, that re-enabling UploadedFileReferenceConverter
of the form
system extension without any additional configuration poses your website at risk for arbitrary file upload. It is required to restrict file uploads by size, mime-type and file-extension as well as storing them to non-guessable locations (/fileadmin/uploads/my-personal-data.pdf
) - see https://typo3.org/security/advisory/typo3-core-sa-2021-002 the vulnerability details.
There is no generic(!) file upload functionality in the TYPO3 core.
- Status changed from New to Closed
Hi, as Oliver already said, there is currently no such implementation in TYPO3. Due to lack of activity here, I'll close this issue now in favour of the related feature request. In case there is still something not working correctly, which is not directly related to the topic of the feature request, please create a new issue with a reference to this one.
Also available in: Atom
PDF