Opened 6 years ago
Last modified 2 years ago
#46544 new defect (bug)
mp3 file with different file mime type and content type when uploading should not be rejected
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | major | Version: | 5.1 |
Component: | Media | Keywords: | needs-patch has-screenshots has-testing-info |
Focuses: | Cc: |
Description
<?php $files = [ 'recording6021333337014136895.mp3', 'SampleAudio_0.7mb.mp3', 'to_test_on_timby_voice_note.m4a' ]; if ( extension_loaded( 'fileinfo' ) ) { foreach ($files as $file ) { $finfo = finfo_open( FILEINFO_MIME_TYPE ); $real_mime = finfo_file( $finfo, $file ); finfo_close( $finfo ); echo "$file $real_mime\r\n"; } }
Results:
recording6021333337014136895.mp3 video/mp4
SampleAudio_0.7mb.mp3 audio/mpeg
to_test_on_timby_voice_note.m4a application/octet-stream
All the files are valid, but recording6021333337014136895.mp3
and to_test_on_timby_voice_note.m4a
because of the mime type.
https://github.com/WordPress/WordPress/commit/3af00578e46efa3b59fb8ed9f4177d632a123a2e is the commit which introduces this issue
Attachments (4)
Change History (9)
#1
follow-up:
↓ 2
@
6 years ago
Welcome to trac and thanks for the report!
recording6021333337014136895.mp3 video/mp4 to_test_on_timby_voice_note.m4a application/octet-stream
The issue with the above files should ideally be fixed by adding right associations in wp_get_mime_types
function inside wp_includes/functions.php
file.
'mp3' => 'video/mp4', 'm4a' => 'application/octet-stream',
The issue with recording6021333337014136895.mp3 video/mp4
has actually resolved by the above approach but the m4a
one is not responding to it!
I downloaded few sample m4a
sample files and they uploaded correctly since the mime-types of those are all audio/x-m4a
, and this is the value returned by get_real_type
function.
Although adding a correct association should work ('m4a' => 'application/octet-stream'
) and the mime-type
of your file is indeed application/octet-stream
I am not sure why it is being rejected! However, none of the m4a
files I downloaded is of application/octet-stream
.
Can you send another m4a
of application/octet-stream
type file for further testing please?
#2
in reply to:
↑ 1
@
6 years ago
Thanks for taking care of it.
I just attached another m4a file (xj.m4a). It was recorded using Vocienote app built in SAMSUNG S8.
Could you explain how you are going to fix it? The fix should work for the following types
- an mp3 file could have a set of mime types such as
audio/mpeg
,video/mp4
- similarly, an m4a file could have mime type
audio/mpeg
,audio/x-m4a
orapplication/octet-stream
This is not a complete list of all variations of possible mime types, because every recording app handles it differently. Adding another set of mime type for mp3,m4a might solve this current bug, but it is very likely that there are other cases we may miss.
Is there a reason that we have to do mime type checking that strict?
Replying to subrataemfluence:
Welcome to trac and thanks for the report!
recording6021333337014136895.mp3 video/mp4 to_test_on_timby_voice_note.m4a application/octet-streamThe issue with the above files should ideally be fixed by adding right associations in
wp_get_mime_types
function insidewp_includes/functions.php
file.
'mp3' => 'video/mp4', 'm4a' => 'application/octet-stream',The issue with
recording6021333337014136895.mp3 video/mp4
has actually resolved by the above approach but them4a
one is not responding to it!
I downloaded few sample
m4a
sample files and they uploaded correctly since the mime-types of those are allaudio/x-m4a
, and this is the value returned byget_real_type
function.
Although adding a correct association should work (
'm4a' => 'application/octet-stream'
) and themime-type
of your file is indeedapplication/octet-stream
I am not sure why it is being rejected! However, none of them4a
files I downloaded is ofapplication/octet-stream
.
Can you send another
m4a
ofapplication/octet-stream
type file for further testing please?
This ticket was mentioned in Slack in #core-media by desrosj. View the logs.
6 years ago
#5
@
2 years ago
- Keywords has-testing-info added
Reproduction Report
I'm providing an updated test report to confirm this issue still exists.
Steps to Reproduce
- In your test WordPress site, navigate to Media.
- Attempt to upload an audio file that has a MIME type of
video/mp4
(e.g. Monday%20at%202-57%20AM.m4a). - 🐞 The uploader responds with the error: "Sorry, you are not allowed to upload this file type."
Environment
- Hardware: MacBook Pro Apple M1 Pro
- OS: macOS 12.6.2
- Browser: Safari 16.2
- Server: nginx/1.23.3
- PHP: 7.4.33
- WordPress: 6.2-alpha-54642-src
Expected Results
- ✅ The uploader should allow audio files with a MIME type of
video/mp4
, which is common for Android.
Actual Results
- ❌ The uploader does not allow upload of an audio file with MIME type
video/mp4
and responds with an error. This occurred for a sample.mp3
and.m4a
file.
Additional Notes
When using macOS Safari, .m4a
files may be converted to .mp3
when using Trac's attachment download link. However, this does not change the MIME type, so the resultant converted .mp3
file should still validate the error. To avoid ambiguity, when downloading contributor-supplied samples, I recommend using a different browser, or curl -O <url-to-file>
instead.
The sample audio file's MIME type was verified using (includes Safari's .mp3
conversion):
$ file -I Monday\ at\ 2-57\ AM* Monday at 2-57 AM.m4a: video/mp4; charset=binary Monday at 2-57 AM.m4a.mp3: video/mp4; charset=binary
A sample iOS-generated .m4a
was verified using:
$ file -I iPhone-sample.m4a iPhone-sample.m4a: audio/x-m4a; charset=binary
Supplemental Artifacts
The sample Android recorder audio file was supplied by @pontifier in #57530.
Recording from phone