Bug #100746: Better handling of images with wrong file ending - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #100746

open

Better handling of images with wrong file ending

Added by Sybille Peters about 1 year ago. Updated 10 months ago.

Status:

New

Priority:

Should have

Assignee:

Category:

File Abstraction Layer (FAL)

Target version:

Start date:

2023-04-25

Due date:

% Done:

Estimated time:

TYPO3 Version:

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

If files with wrong file ending (e.g. png image with .jpg or vice versa) are uploaded there are some problem which are difficult to detect if one is not aware of it.

This may vary, depending on the Webserver configuration and graphics tool used (Image Magick or Graphics Magick).

Note: Behaviour may vary depending on TYPO3 version, most of my tests were with v11, should be verified with latest main.

I describe what happens on my system.

for processed files, a processed file with size 0 is created (Graphics Magick does not convert it and shows an error message, but this is not displayed in BE)
in the BE, no image is displayed as preview
in the FE, the image is not scaled
no error messages are displayed and no errors are logged (severity >= ERROR)

Unfortunately, I have a number of these files, noticed this when searching for files with size 0 (_processed files are created with size=0).

Suggested changes¶

if possible show an error on upload if the wrong file ending is used or refuse to upload the file (requires 100% correct detection of wrong file ending, at least for images, which may be difficult, should probably be configurable)
or use correct file ending when creating the processed file (e.g. as detected by graphics tool)
or do not create processed files with file ending 0, possibly fallback to creating a placeholder image if the created file has size 0
show errors / log messages

System¶

TYPO3 11.5.26
Graphics Magick (gm)

Reproduce¶

(1)

1. Upload a file with wrong file ending (e.g. previously mv, do not convert 1.jpg 1.png)
2. Insert file in "Text & Media" as "asset", specify smaller height / width, view in FE (check if scaled), compare with file which is ok
3. activate preview images in file list

Expected:

error message or fail on trying to upload image with wrong file extension or error message when creation of scaled image fails (actual: there is no flash message and no log message)
image is scaled in FE or error message is diplayed. (Actual: is not scaled)
preview image is displayed in filelist. (Actual: is not)

How to detect affected processed files¶

On command line:

find htdocs/fileadmin/_processed -type f -size 0

The file name of actual file can be derived from the processed file name or looked up in DB sys_file_processedfile.original => sys_file.uid.

Resources / Tools¶

gm This is what was used by TYPO3 to create the thumbnail image in the filelist

'/usr/bin/gm' 'convert' -interlace None -auto-orient +profile '*' -sample '64'x'64' 'png:/var/www/site-uol11/htdocs/fileadmin/test/problems/Koala.png[0]' '/var/www/site-uol11/var/transient/preview_6908622721787002005.png'

output:

/usr/bin/gm identify: Improper image header (/var/www/site-uol11/var/transient/preview_6908622721787002005.png) [No such file or directory].

file

$ file htdocs/fileadmin/test/problems/Koala.png

output:

JPEG image data, JFIF standard 1.02, resolution (DPI), density 96x96, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=7, datetime=2009:03:12 13:48:28], baseline, precision 8, 1024x768, components 3

file can be used to show the mime type:

$ file -b --mime-type htdocs/fileadmin/test/problems/Koala.png

shows:

image/jpeg

or the (correct) extension(s):

$ file  --extension htdocs/fileadmin/test/problems/Koala.png

shows:

jpeg/jpg/jpe/jfif

PHP exif_imagetype

https://www.php.net/manual/en/function.exif-imagetype.php

also determines real image type.

Actions

Copy link

Updated by Sybille Peters about 1 year ago

Description updated (diff)

Actions

Copy link

Updated by Sybille Peters about 1 year ago

In my tests, the internal information seems to be inconsistent, e.g. with above example which is a jpg but poses as a .png file:

$mimetype = $currentFileObject->getMimeType();
$extension = $currentFileObject->getExtension();
$absoluteFilePath = Environment::getPublicPath() . '/' . $currentFileObject->getPublicUrl(false);
$type = $currentFileObject->getType();
$isImage = $currentFileObject->isImage();
if ($isImage) {
    $realImageType = \exif_imagetype($absoluteFilePath);
    $this->io->writeln(sprintf('file: extension=%s mimetype=%s, type=%d, real type=%d', extension, mimetype, type, realImageType));
}

result:

file: extension=png, mimetype=image/png, type=2, real type=2

So, mimetype contains the incorrect mimetype ("image/png"), but type contains the correct type (IMAGETYPE_JPEG = 2), see https://www.php.net/manual/en/function.exif-imagetype.php

Actions

Copy link

Updated by Sybille Peters about 1 year ago

The mimetype is derived from the file extension in FileInfo::getMimeType:

public function getMimeType()
{
    $mimeType = false;
    if ($this->isFile()) {
        $fileExtensionToMimeTypeMapping = $GLOBALS['TYPO3_CONF_VARS']['SYS']['FileInfo']['fileExtensionToMimeType'];
        $lowercaseFileExtension = strtolower($this->getExtension());
        if (!empty($fileExtensionToMimeTypeMapping[$lowercaseFileExtension])) {
            $mimeType = $fileExtensionToMimeTypeMapping[$lowercaseFileExtension];