mahara-contributors team mailing list archive

[Aaron Wells <1249858@xxxxxxxxxxxxxxxxxx>]

Okay, so there are a few things going on here. I ran some tests using
FF, Ubuntu 12.04, and PHP 5.3.12 (my dev environment)

1. If you upload an MP3 file, in Mahara 1.7 or 1.6, it doesn't get
recognized as an audio file.

2. An MP3 file *does* get recognized as an audio file in Mahara 1.8, but
this is because of this patch ( https://reviews.mahara.org/#/c/2474/3 )
which tells it to trust the mimetype passed by the browser.

3. The call to finfo() in file_mime_type() currently does not work. BUT,
if I remove the magicpath argument (which according to the docs lets PHP
use its "internal" one), then it *does* work.

4. The part of file_mime_type() where it falls back to analyzing the
uploaded file's file extension, doesn't work when you're uploading a
file. Because in that case, the $file we pass in to file_mime_type() is
the gibberish filename of a PHP temporary upload file.

So... I think this is the course of action we need to take:

For 1.6 & 1.7:

1. Add a config-defaults.php option $cfg->pathtomagicdb that allows the
admin to configure the magicpath. The default (NULL) will continue with
the current magicdb behavior. Setting boolean FALSE will use PHP's
internal one. Setting a path will use the db at that path. This will
allow affected systems to fix the problem, while not changing the
behavior for other systems.

2. Add an optional parameter to file_mime_type() to take the original
filename and look at the file extension on that. Alter
ArtefactTypeFile::new_file() to use this option (when uploading a file)

For 1.8:

1. The same stuff as for 1.7

2. Also, revert patch https://reviews.mahara.org/#/c/2474 , which tells
Mahara to use the browser-supplied mimetype. (Or at least reverse the
logic so that we trust file_mime_type() first, and if that provides
nothing, we check the browser-supplied mimetype)

For 1.9.0 & later:

1. The same stuff as for 1.8

2. Also, we change the default setting of $cfg->pathtomagicdb to FALSE.
(Which is okay to do because this is a major release)

3. And we get rid of the logic in file_mime_type that checks for whether
we can use FILEINFO_MIME_TYPE or FILEINFO_MIME. The FILEINFO_MIME_TYPE
functionality was added in PHP 5.3, and that's the only version we
support now.

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1249858

Title:
  Mahara can't figure out mime types because of a finfo() bug

Status in Mahara ePortfolio:
  Confirmed
Status in Mahara 1.6 series:
  Confirmed
Status in Mahara 1.7 series:
  Confirmed
Status in Mahara 1.8 series:
  Confirmed
Status in Mahara 1.9 series:
  Confirmed

Bug description:
  There have been several notable Mahara bugs based around the fact that
  our current handling of mimetypes is broken.

  See for instance:
   - https://bugs.launchpad.net/mahara/+bug/1220639
   - https://bugs.launchpad.net/mahara/+bug/1249166

  The problem is this:

  1. You can't really trust the mimetype that the browser sends to you, because different browsers send different wacky things
  2. Mahara has long used its own function file_mime_type() in lib/file.php for this purpose
  3. file_mime_type() preferentially uses finfo() to check the mimetype. But, there's a bug in finfo() with an external magic db, which is how it is distributed on Ubuntu presently: https://bugs.php.net/bug.php?id=61940
  4. file_mime_type() falls back to mime_content_type(). But that's now deprecated
  5. If neither of those works, we fall back to trusting what the browser told us, which isn't really the best (see #1)

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1249858/+subscriptions