Issues

ZF-9278: Problems with magic files

Issue Type: Improvement Created: 2010-02-26T15:47:02.000+0000 Last Updated: 2010-03-12T02:36:30.000+0000 Status: Resolved Fix version(s): - 1.10.3 (01/Apr/10)

Reporter: Marc Bennewitz (private) (mabe) Assignee: Thomas Weidner (thomas) Tags: - Zend_Validate_File

Related issues: Attachments: - MimeType.php.diff

Description

On some systems the magic file can't used by finfo. On using it php errors will be reported and tests fails. I know this is not directly a ZF problem but Zend_Validate_File_Mimetype should throw an exception on setting an invalid magic file or if finfo isn't supported by php and the magic file can't used.

Additionally the first found magic files will be used (if not set) without testing its format.

To solve this 1. use the function based interface of finfo than an invalid magic file can detected and throw an exception 2. use the opened finfo resource (opened on setMagicFile to check format) within isValid 3. throw an exception finfo_file returns false -> it returns application/octed-stream if no matches was found 4. throw an exception on setMagicFile if finfo isn't available 5. set systems magic file on constructor (if no option) but don't throw an exception if invalid (skip magic file if it has an invalid format and check the next) 6. add and use a valid magic file on tests

Comments

Posted by Thomas Weidner (thomas) on 2010-02-26T15:52:20.000+0000

Changing from patch to improvement as there was no patch added

Posted by Marc Bennewitz (private) (mabe) on 2010-02-26T16:02:16.000+0000

patch added (Currently only tested on php 5.3.1)

Posted by Thomas Weidner (thomas) on 2010-02-26T16:05:08.000+0000

No to 1... no difference to object interface except that you must additionally unset the resource on a failure.

No to 2 (see 1)

No to 3... a false from finfo can also mean any other error and is not limited to a not recognised mimetype

No to 4... an automatic found magicfile should not throw an exception

No to 5... this is actually done afterwards to reduce payload

6: This is already done

Posted by Marc Bennewitz (private) (mabe) on 2010-02-26T16:16:24.000+0000

to 1: I set the resource only if finfo_open retunred a resource and on destructor i close it

to 3: yes a false from finfo_file means there was an error - on error i throw an exception else it returns application/octed-stream (on my tests) -> I reset this to null

to 4: the automatic file detection is done on constructor and will catch the exception

to 5: within trunk the detection was on getMagicFile ?

to 6: I couldn't find it - where is it located ?

Posted by Marc Bennewitz (private) (mabe) on 2010-02-26T18:42:42.000+0000

patch for changes in tests

Posted by Thomas Weidner (thomas) on 2010-03-04T13:31:12.000+0000

No for the patch... it adds not allowed behaviour and also errors

Posted by Marc Bennewitz (private) (mabe) on 2010-03-05T09:42:31.000+0000

Can you tell me which not allowed behavior do you mean and where errors are reported, please?

Posted by Thomas Weidner (thomas) on 2010-03-08T12:32:34.000+0000

You were adding an exception within isValid() which is not allowed.

Additionally you added some other problems by erasing the check for save_mode which integrates already solved issues.

Posted by Marc Bennewitz (private) (mabe) on 2010-03-08T13:25:30.000+0000

??You were adding an exception within isValid() which is not allowed.?? yes, but if finfo_file returns false I'm sure it's an internal error of finfo because it returns "application/octet-stream" if mimetype could not detect. (finfo_file: Returns a textual description of the contents of the filename argument, or FALSE if an error occurred.) -> On such cases than we need to add a new validate message and return false.

??Additionally you added some other problems by erasing the check for save_mode which integrates already solved issues.?? I will do some tests with it - don't tested it now

I see you closed ZF-9320, but: 1. if new finfo failes PHP-Notices are reported - This is also not allowed (if possible) on ZF 2. $mime isn't false if mime database is invalid. -> this is why I implemented it as open_finfo in my patch 3. You open an finfo instance twice -> on setMagicFile and on isValid /:

<pre class="highlight">
$const = defined('FILEINFO_MIME_TYPE') ? FILEINFO_MIME_TYPE : FILEINFO_MIME;
$mime = new finfo($const, __FILE__);
// PHP Notice:  finfo::finfo(): Warning: offset `<?php' invalid in .../finfo_test.php on line 4
// PHP Notice:  finfo::finfo(): Warning: type `<?php' invalid in .../finfo_test.php on line 4
// PHP Notice:  finfo::finfo(): Warning: offset `$const = defined('FILEINFO_MIME_TYPE') ? FILEINFO_MIME_TYPE : FILEINFO_MIME;' invalid in .../finfo_test.php on line 4
// PHP Notice:  finfo::finfo(): Warning: type `$const = defined('FILEINFO_MIME_TYPE') ? FILEINFO_MIME_TYPE : FILEINFO_MIME;' invalid in .../finfo_test.php on line 4
// PHP Notice:  finfo::finfo(): Warning: offset `$mime = new finfo($const, __FILE__);' invalid in .../finfo_test.php on line 4
// PHP Notice:  finfo::finfo(): Warning: type `$mime = new finfo($const, __FILE__);' invalid in .../finfo_test.php on line 4
// PHP Notice:  finfo::finfo(): Warning: offset `var_dump($mime);' invalid in .../finfo_test.php on line 4
// PHP Notice:  finfo::finfo(): Warning: type `var_dump($mime);' invalid in .../finfo_test.php on line 4
// PHP Warning:  finfo::finfo(): Failed to load magic database at '.../finfo_test.php'. in .../finfo_test.php on line 4

var_dump($mime);
// object(finfo)#1 (0) {
// }

Additionally: * getMagicFile don't return mime_magic.magicfile if finfo isn't available but mime_content_type is * setMagicFile don't throw an exception if finfo isn't available

Posted by Thomas Weidner (thomas) on 2010-03-12T02:36:30.000+0000

Fixed as discussed within IRC

Have you found an issue?

See the Overview section for more details.

Copyright

© 2006-2016 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.

Contacts