[wp-trac] [WordPress Trac] #40175: Upload Validation / MIME Handling

[WordPress Trac]

#40175: Upload Validation / MIME Handling
-------------------------------------------------+-------------------------
 Reporter:  blobfolio                            |       Owner:  joemcgill
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  5.1
Component:  Media                                |     Version:  4.7.3
 Severity:  major                                |  Resolution:
 Keywords:  has-unit-tests has-patch needs-      |     Focuses:
  testing early                                  |  administration
-------------------------------------------------+-------------------------

Comment (by joemcgill):

 [attachment:"40175.3.diff"] is a first pass at a new approach to this
 problem, heavily influenced by all of @blobfolio's previous work on this
 issue. The overall idea is to simplify/consolidate the logic in
 `wp_check_filetype_and_ext()` so that there are distinct separation of
 concerns between managing the mime types known to WordPress, guessing the
 mime type of a file, possibly renaming a file that has the wrong
 extension, and determining if a file should be allowed.

 **Managing registered mime types:** This would happen in
 `wp_get_file_types()`, which is similar to the old `wp_get_mime_types()`,
 but supports an array of supported mime types for each file extension.

 **Guessing a file's mime type:** This was previously handled internally in
 `wp_check_filetype_and_ext()` with some logic previously being
 consolidated to `wp_get_image_mime()`. This would create a new function
 called `wp_get_mime_type()` which loops through a list of registered "mime
 type guessers" to determine the actual mime type. One of the guessers is,
 naturally, `wp_get_image_mime()`. Additionally, all other `finfo_file()`
 logic is consolidated to a new function, `wp_get_file_mime()`.

 **Possibly rename files with the wrong extension:** Traditionally,
 `wp_check_filetype_and_ext()` has attempted to fix some image files if
 they are named incorrectly. This functionality would now be consolidated
 to `wp_maybe_rename_file()`, though, I'm curious if we really need to
 maintain this behavior anymore.

 **Determining if a file type is allowed:** This now becomes a simple check
 in `wp_is_file_type_allowed()` by making use of the new
 `wp_get_allowed_file_types()` function, which grabs the full list of known
 mime types and filters out any types that aren't supported based on
 extensions or user capabilities.

 Most of these changes are cosmetic, simplifying the code and making it
 easier to test. That said, there are two major changes worth noting if we
 go this route.

 1. WordPress can now map a single extension to multiple supported mime
 types.
 2. If a file cannot be verified or if the mime type is not supported for
 that extension, the file will not be able to be uploaded.

 Plugins will be able to extend both the file type list, and the means of
 guessing file types, in order to modify default behavior and I've
 attempted to support most cases where plugins were already doing the
 former by way of the `mime_types` and `upload_mimes` filters.

 **Next steps**

 I would appreciate feedback from people who are currently having problems
 uploading files to see if this approach fixes many of the blocked uploads
 problems we're having. If this approach works, we'll need to determine the
 best approach for deprecating the previous mime type functions in core
 (currently there are a few places I assume we will want to deprecate, but
 those are commented out).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/40175#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform