[#43345] - MediaHelper: proper check if file is an image (#42105)
- Fixed in Code Base
- 17 May 2024
- Medium
- Build: 4.4-dev
- # 43345
- Diff
- coderiekelt:4.4-dev
User tests: Successful: Unsuccessful:
Pull Request for Issue #42105.
Summary of Changes
- Changed
MediaHelper.phpto properly check if the uploaded file is actually an image, instead of assumingtrue.
Testing Instructions
Upload a PDF file to the media library, this should work properly. Uploading images will also still work fine in accordance with previous behavior.
Actual result BEFORE applying this Pull Request
Uploading a PDF fails, providing an unhelpful error to the user. When checking the request in within the browser the message is along the lines of "This is not a valid image".
Expected result AFTER applying this Pull Request
Uploading a PDF works fine, uploading images still follows the previous behavior.
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
After some digging it appears that this error occurs if the exif extension is not loaded.
A simple test script to get the MIME type from a blank PDF file yielded this result:
getimagesize: unknown (false)
exif_imagetype: application/octet-stream
Meaning this problem will not occur if the exif extension is loaded, since it will return application/octet-stream. (Which is properly detected further down in the function.)
If exif is not loaded it will fail, since the MediaHelper will assume that the file is always an image and just gives up after trying getimagesize() due to the way the way the if statement within this function is structured.
i can confirm that this issue occurs when exif is not available.
Some history #16086
Which should have been fixed with #16091
@brianteeman Yes, but that code has been modified meanwhile. In PR #16091 it was checked if the file name extension is in the allowed list for images, $params->get('image_extensions'), and if that was the case, the static::getMimeType method was called with value true for the $isImage parameter.
That was right, and that's why it worked with that PR.
But later the code was changed so it uses the list of allowed file name extensions for uploads, which can also be e.g. a video or a PDF file:
params->get('restrict_uploads_extensions', 'bmp,gif,jpg,jpeg,png,webp,ico,mp3,m4a,mp4a,ogg,mp4,mp4v,mpeg,mov,odg,odp,ods,odt,pdf,png,ppt,txt,xcf,xls,csv')
The static::getMimeType method then checks with EXIF only when that parameter has value true, but that would fail for a video or PDF file:
joomla-cms/libraries/src/Helper/MediaHelper.php
Lines 92 to 96 in 4e36f77
So to me the change made by this PR here seems to be right. It replaces the hard-coded true value by the result of the static::isImage call, which does nothing else than checking the file name extension again for valid values for images.
| Labels |
Added:
PR-4.4-dev
|
||
I have tested this item ✅ successfully on fde2fe8
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43345.
Hm, the getMimeType() should not care about isImage, it should read the file mime for any file, regardless its type.
But that another issue.
As for now the PR is okay.
I have tested this item ✅ successfully on fde2fe8
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43345.
| Status | Pending | ⇒ | Ready to Commit |
r2c
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43345.
| Labels |
Added:
RTC
bug
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-05-17 13:31:38 |
| Closed_By | ⇒ | MacJoom |
Thank you!
unable to test as I cannot replicate the reported error