Cannot upload WOFF files (unless you're a multisite super-admin?)

[eddiemcham]

This is a follow-up to #39550.

Our team develops fonts and scripting behavior for minority languages, and we have a WP multisite in which we heavily use and render WOFF files. To facilitate this, I have not only specified WOFF as an acceptable file type in the multisite settings page, but implemented upload_mimes for application/x-font-woff.

Today, a coworker informs me she can no longer upload WOFFs to her Media Library. She is told Sorry, due to security restrictions, this file cannot be uploaded. What's weird is I was able to do so, but her page does not recognize it; it throws an error message treating the WOFF as a missing file.

I found this thread from a Google search and see that apparently something regarding mime-types has recently changed. It wasn't clear to me from reading the thread what the fix was. I saw references to a plugin, but I really don't like the idea of having to slap on another plugin just to fix a WP code bug. We are deliberately trying to keep our plugin usage to a minimum to avoid possible incompatibilities between them. Nor can we downgrade to earlier WP versions because of security issues in the previous dot-dot releases.

I've attached one of our WOFF files that was uploaded on June 22, 2016 and worked fine then. Now, if we try re-uploading that same file to the Media Library, it fails. So we know it's not an issue with the WOFF file itself.

As this is a critical feature on our Arabic-language sites, I do need to request that this be made a high-priority issue. Thank you.

~ Eddie McHam

[eddiemcham]

Originally uploaded to Media Library on June 22, 2016 and worked fine. Today, we cannot re-upload this or any other WOFF files to our Media Libraries.

[swissspidy]

Thanks for your report @eddiemcham.

We're definitely aware of the various media issues in the most recent version (#40078, #40085, #40075, just to name a few) and everyone here works hard to resolve these issues. Just note that putting "URGENT" into the title doesn't speed things up.

[eddiemcham]

My apologies, it's my first time reporting a bug here, and I didn't see the drop-down where I could select severity='blocker' until after I'd already edited the title.

That said, is the correct MIME type supposed to be application/font-woff (without the x-)? If so, I can try modifying our functions.php accordingly.

If not, then is that Disable Real MIME Check plugin supposed to work on version 4.7.3? From its description, I assumed no.

My coworker tells me we have 2 Arabic-language projects this month that will need this issue dealt with. I will have to test fixes on my local environment, then QA, and finally production.

Thanks, Eddie

[lukecavanagh]

@eddiemcham

Try application/font-woff instead of application/x-font-woff.

<?php
add_filter('upload_mimes','add_custom_mime_types');
        function add_custom_mime_types($mimes){
                return array_merge($mimes,array (
                        'woff' => 'font-woff',
                ));
        }

[lukecavanagh]

WOFF file uploaded without security warning to media library

[eddiemcham]

“LateefGR-Regular.woff” has failed to upload.
Sorry, this file type is not permitted for security reasons.

On my local environment, I tried just removing the x- from my script, then commenting out the entire script and implementing yours above. Neither had any effect. Also tried both the multifile uploader and regular upload pages. Same result.

BTW, WOFF is listed as one of my Upload File Types in the multisite settings. Just throwing that in to eliminate that cause.

[lukecavanagh]

@eddiemcham

Care to share that WOFF file for testing.

[blobfolio]

@eddiemcham, you can fix the issue for your site without installing an extra plugin by following @lukecavanagh's suggestion, only the type you insert needs to be the type that PHP thinks it is, not necessarily the objectively correct type (font/woff). To figure that out, you can adapt the quickie code snippet at https://core.trac.wordpress.org/ticket/39550#comment:135

This workaround is only necessary in cases where your particular version of PHP believes a file to be of type application/*. I mention it in case you run into issues with any other file types, as most of the time when PHP gets the type wrong, it will think it is application/something.

As @swissspidy mentioned, this is currently being tackled on a couple of different fronts, so should be largely resolved in the next release or two.

[eddiemcham]

Replying to lukecavanagh:

@eddiemcham

Care to share that WOFF file for testing.

I wish I could, but that particular font is not yet ready for public release, so I'm not authorized to share it out here. However, it acts exactly the same as the Scheherazade-Regular WOFF file I attached to this issue earlier.

I only used that Lateef WOFF because Scheherazade had already been uploaded way back in June.

[eddiemcham]

@blobfolio : Thanks, I'll give that a try and get back to you. :)

[eddiemcham]

Well, that was certainly unexpected. I ran the test.php on 3 different WOFF files and got the same result:

MIME: application/octet-stream

So I applied that to my functions.php script and can now upload the WOFF to my local WP's Media Library, and the page no longer throws errors about missing WOFF files.

Before I test this on our QA and production environments, I guess I should ask why the change, and is it likely to change back to x-font-woff or font-woff?

[blobfolio]

Replying to eddiemcham:

Before I test this on our QA and production environments, I guess I should ask why the change, and is it likely to change back to x-font-woff or font-woff?

It's actually PHP that is coming up with application/octet-stream, not WordPress. Unfortunately that particular function (part of the fileinfo extension), while helpful sometimes, is also really inconsistent from environment to environment (hence all the trouble people are having).

If your production environments are identical to your staging setup, then they should be equally wrong in their assessment of what a WOFF file is, in which case the identical fix will work. If they're a little different, the general concept of the workaround is still good, you might just need to slug a different media type in there.

[eddiemcham]

OK thanks again. I'll try this on our QA environment and see what happens.

[eddiemcham]

Hello again,

Afraid we're back to square one, but I think I know why now.

I modified our functions.php to redefine WOFFs as application/font-woff and confirmed I could upload WOFFs and that they render fine. I did have to delete and re-upload existing WOFF files from the Media Library so Wordpress would reset their MIME types from x-font-woff to font-woff.

However, my coworker still gets the security - cannot upload this file type message. She can upload other types, like PNGs. So the question remains: Why can I upload WOFFs but she can't???

Then I realized I'm the multisite super-admin, and she's only the admin to her particular sites. So as a test, I temporarily made her a multisite super-admin like me.

Now she can upload WOFFs, but Wordpress tags them as application/octet-stream, and her pages throw errors because they're now looking for font-woff attachments due to the earlier change I made to functions.php.

Did something else change recently in WP that only allows multisite super-admins to upload WOFFs? As a matter of security, I can't just go and make her and everyone else on our team super-admins.

Now what do I do?

~ thx, Eddie

[blobfolio]

Replying to eddiemcham:

Then I realized I'm the multisite super-admin, and she's only the admin to her particular sites. So as a test, I temporarily made her a multisite super-admin like me.

Hi Eddie,

Multisite has an extra layer: the master upload_mimes list is further filtered according to the rules set up for each site (at .../wp-admin/network/settings.php). You probably need to add WOFFs there for non-super-admins to be able to upload them.

To confirm, when your colleague received an application/octet-stream type, did you try uploading that same file to the same sub-site? I'm wondering if there is something peculiar with that one file or site (rather than results varying by user).

[eddiemcham]

If you mean the Upload file types text field, then yes, I added woff to that list last year when we first started working with web fonts in WordPress. It's still listed there now, and it's always cascaded down to each team's site in the network.

When I uploaded her WOFF, WP tagged it as application/font-woff. When she uploaded it to another site (as part of the super-admin test), it was tagged application/octet-stream...presumably because in her context WordPress still didn't know what type of file it was.

So there's something different going on between her account/role/permissions and mine.

By the way, I've since turned off her super-admin status, so at this point, she's back to not being able to upload WOFFs again.

[SergeyBiryukov]

Replying to eddiemcham:

I modified our functions.php to redefine WOFFs as application/font-woff

Why not application/octet-stream, as you indicated in comment:11?

Did something else change recently in WP that only allows multisite super-admins to upload WOFFs?

Multisite super admins have the unfiltered_upload​ capability, so no additional file type checks are performed. That's not a recent change, but it would explain the difference in results.

[SergeyBiryukov]

Replying to SergeyBiryukov:

Multisite super admins have the unfiltered_upload​ capability, so no additional file type checks are performed.

Scratch that, now I see that it's only true if ALLOW_UNFILTERED_UPLOADS constant is also defined. Maybe you do have it defined though?

[eddiemcham]

I'm not sure the MIME type is the issue now, so much as my colleague's Admin role no longer letting her upload her WOFFs.

Whatever changed 1 or 2 point releases ago that suddenly cut off Admins from uploading WOFFs needs to be undone.

I read in similar recent threads about setting ALLOW_UNFILTERED_UPLOADS to true, but that sounds like a security no-no. What if someone hacks one of our Admin's accounts and starts uploading malicious stuff?

[eddiemcham]

I'm testing a workaround by creating another folder where my colleagues can FTP their WOFFs directly. Then I'll modify our CSS rendering code so that font-face looks for the WOFF files in the FTP folder instead of the Media Library.

In other words, we're no longer using the WP Media Library for WOFFs. No more MIME types, no more admin-vs-superadmin lockouts, and no more security errors.

Thanks to everyone for your help! :)

[blobfolio]

This ticket is being merged into #40175. Please continue related discussion there.

[joemcgill]

Replying to eddiemcham:

I'm not sure the MIME type is the issue now, so much as my colleague's Admin role no longer letting her upload her WOFFs.

Hi @eddiemcham. Following up, this is definitely a MIME issue. As others have indicated, the problem is the way WordPress is verifying that the uploaded file really is what it claims to be. If the specific server isn't able to verify that the file is a WOFF file, it will respond with application/octet-stream (a common default when the filetype is unknown to your server). Users without super-admin privileges are not able to upload application/octet-stream files on multi-site, which is why this is failing for your colleague.

There are several related cases of this sort of thing happening in different configurations so combining this conversation in #40175 will help us address all cases.

[eddiemcham]

@joemcgill ~

Thank you for helping me understand the cause of the issue. We have implemented a workaround on our end, so we're good now.

Have a good weekend. :)

~ Eddie