Make WordPress Core

Changes between Version 1 and Version 2 of Ticket #40175, comment 80

04/30/2020 07:31:01 PM (21 months ago)


  • Ticket #40175, comment 80

    v1 v2  
    88The troubling part about this bug (and its perpetual delay for a more perfect solution) for me is that while the logic changed to explicitly deny files whose extensions don't match their determined mime type, the interface for whitelisting didn't. So in vanilla multisite WordPress I am told I can state I want to allow "css" file extension uploads, but the code doesn't care because the file itself doesn't match behind the scenes and all I'm told is "not allowed for security reasons".  If I had a field for telling it the mime types I want to allow matched with their extensions and/or the error was more explicit about what mime type my file was diagnosed as and thus why it was excluded, then I would have recourse without waiting for the solution to be implemented.  I could add my own workarounds as needed for whatever obscure combination of mime type and file extension is holding up each of our work (and to be honest, uploading CSS files to WordPress isn't exactly obscure in my mind...).
    10 EDIT: Add text/x-asm and text/x-c as other possibilities for css files being misidentified by fileinfo and outside of the scope of the current code.
     10EDIT: I've further discovered that when fileinfo thinks the .css file is assembly or c language (text/x-asm or text/x-c) instead of text/plain, then I have to introduce an entirely new elseif to handle those cases.  This needs attention.