Last modified: 2013-09-04 10:36:29 UTC
Upon updating from the 1.17beta to the 1.17rc1 the allowing of office 2007 files is still not detecting the correct mime type for .doc and it does not allow .docx files to be uploaded giving the error of "application/x-opc+zip" are not allowed. The .doc still gives the "File extension does not match MIME type" error. I attempted to copy the black list to LocalSetting.php and comment out the ones related to office but it crashes the wiki with an internal error: Internal error From wikitest Jump to: navigation, search error storing file in '/var/tmp/phpdeguPj.docx': directorycreateerror; /var/www/html/wikitest/images/temp/8/8b Backtrace: #0 /var/www/html/wikitest/includes/upload/UploadBase.php(634): UploadStash->stashFile('/var/tmp/phpdeg...', Array, NULL) #1 /var/www/html/wikitest/includes/upload/UploadBase.php(646): UploadBase->stashSessionFile(NULL) #2 /var/www/html/wikitest/includes/specials/SpecialUpload.php(367): UploadBase->stashSession() #3 /var/www/html/wikitest/includes/specials/SpecialUpload.php(461): SpecialUpload->showUploadWarning(Array) #4 /var/www/html/wikitest/includes/specials/SpecialUpload.php(192): SpecialUpload->processUpload() #5 /var/www/html/wikitest/includes/SpecialPage.php(578): SpecialUpload->execute(NULL) #6 /var/www/html/wikitest/includes/Wiki.php(251): SpecialPage::executePath(Object(Title)) #7 /var/www/html/wikitest/includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest)) #8 /var/www/html/wikitest/index.php(114): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest)) I tried both a chmod 666 and 777 on the images directory with the same result based on the error storing file.
(In reply to comment #0) > Upon updating from the 1.17beta to the 1.17rc1 the allowing of office 2007 > files is still not detecting the correct mime type for .doc and it does not > allow .docx files to be uploaded giving the error of "application/x-opc+zip" > are not allowed. So it didn't work in 1.17betz or 1.17rc1, right? Did it work in 1.16? > The .doc still gives the "File extension does not match MIME > type" error. This is the correct behavior.
(In reply to comment #1) > (In reply to comment #0) > > Upon updating from the 1.17beta to the 1.17rc1 the allowing of office 2007 > > files is still not detecting the correct mime type for .doc and it does not > > allow .docx files to be uploaded giving the error of "application/x-opc+zip" > > are not allowed. > So it didn't work in 1.17betz or 1.17rc1, right? > Did it work in 1.16? > > The .doc still gives the "File extension does not match MIME > > type" error. > This is the correct behavior. Correct, I could not get the .docx to work in 1.17beta, 1.17rc1 or 1.16. If that is the correct behavior for a .doc then I will have to disable the checking as there are 3 different versions of office being used on site .docx (2007 and 2010 format), .doc (saved from 2007 or 2010) and .doc (saved from 2003). Thanks
Just to clarify, can you upload normal files fine (like a .jpg or some other format that's commonly uploaded). >If that is the correct behavior for a .doc then I will have to disable the >checking as there are 3 different versions of office being used on site .docx >(2007 and 2010 format), .doc (saved from 2007 or 2010) and .doc (saved from >2003). Docx files being blacklisted by default is the desired behaviour (concerns over GIFAR vulnerability). However they should be upload-able if application/x-opc+zip is removed from $wgMimeTypeBlacklist, and add to the allowed mime types. The exception about directory creation is not supposed to happen unless MediaWiki really can't create the needed subdirectories, and shouldn't be related to the type of file being uploaded.
(In reply to comment #3) > Just to clarify, can you upload normal files fine (like a .jpg or some other > format that's commonly uploaded). Other uploads seem to work fine in the live 1.16.5 I just just tried my test 1.16.5 and 1.17rc1 on a seperate machine and .jpg is having issues uploading. Complaining about not being able to create directory public/?/?? mode 511. Which I must have missed a directory change. Is the directory documents are stored in not "images"? The error makes sense as I cannot seem to find a directory "public" directory anywhere. It is saying the error is occuring in GlobalFunctions.php line 2179. I'm thinking I should just make a fresh install of 1.17 now that is released. Then migrate the settings and data from the live wiki backup to the test environment and go from there. If that resolves it I will change the allowed list and see if that appeases the end users of the wiki. It is very possible that trying some of the things people have done to get around the uploading issue has caused some corruption that finially decided to show its face. Thanks! > >If that is the correct behavior for a .doc then I will have to disable the > >checking as there are 3 different versions of office being used on site .docx > >(2007 and 2010 format), .doc (saved from 2007 or 2010) and .doc (saved from > >2003). > Docx files being blacklisted by default is the desired behaviour (concerns over > GIFAR vulnerability). However they should be upload-able if > application/x-opc+zip is removed from $wgMimeTypeBlacklist, and add to the > allowed mime types. The exception about directory creation is not supposed to > happen unless MediaWiki really can't create the needed subdirectories, and > shouldn't be related to the type of file being uploaded.
(In reply to comment #4) > Complaining about not being able to create directory public/?/?? mode 511. > Which I must have missed a directory change. Is the directory documents are > stored in not "images"? The error makes sense as I cannot seem to find a > directory "public" directory anywhere. It is saying the error is occuring in > GlobalFunctions.php line 2179. > "public" is a placeholder which is automatically replaced by $wgUploadPath, because some people do not appreciate leaking this path to the outside world.
>"public" is a placeholder which is automatically replaced by $wgUploadPath, >because some people do not appreciate leaking this path to the outside world. Of course the jokes on them because image magick leaks that in the image metadata on any (png) thumb it makes :D
(In reply to comment #4) > (In reply to comment #3) > > Just to clarify, can you upload normal files fine (like a .jpg or some other > > format that's commonly uploaded). > > Other uploads seem to work fine in the live 1.16.5 I just just tried my test > 1.16.5 and 1.17rc1 on a seperate machine and .jpg is having issues uploading. > Complaining about not being able to create directory public/?/?? mode 511. > Which I must have missed a directory change. Is the directory documents are > stored in not "images"? The error makes sense as I cannot seem to find a > directory "public" directory anywhere. It is saying the error is occuring in > GlobalFunctions.php line 2179. > > I'm thinking I should just make a fresh install of 1.17 now that is released. > Then migrate the settings and data from the live wiki backup to the test > environment and go from there. If that resolves it I will change the allowed > list and see if that appeases the end users of the wiki. It is very possible > that trying some of the things people have done to get around the uploading > issue has caused some corruption that finially decided to show its face. > > > Thanks! > > > >If that is the correct behavior for a .doc then I will have to disable the > > >checking as there are 3 different versions of office being used on site .docx > > >(2007 and 2010 format), .doc (saved from 2007 or 2010) and .doc (saved from > > >2003). > > Docx files being blacklisted by default is the desired behaviour (concerns over > > GIFAR vulnerability). However they should be upload-able if > > application/x-opc+zip is removed from $wgMimeTypeBlacklist, and add to the > > allowed mime types. The exception about directory creation is not supposed to > > happen unless MediaWiki really can't create the needed subdirectories, and > > shouldn't be related to the type of file being uploaded. maybe if you set chmod 777 on images directory it will work.
Is this still an issue in 1.19 or 1.20?
Likely yes. The behavior changed in 1.17, you needed to explicitly enable doc and docx uploads and allow opc In 1.19 (or there about) Tim added the detectZipType, that makes it so that you no longer need to remove 'opc' files from the mimeblacklist. However, that leaves bug 38432 as a bug between 1.19 and trunk. This isuse is probably affected by all those changes, and I don't think any of it was ever backported.
