Last modified: 2006-02-01 04:46:20 UTC
I have been wrestling with this issue for some time now. The Mediawiki version is actually 1.4.14, but this has been an issue for some time now. When a user tries to upload an image (png, jpg, gif), we're not trying to do anything weird, they get a "The file is corrupt or has an incorrect extension. Please check the file and upload again." error. I've read the FAQ: http://meta.wikimedia.org/wiki/MediaWiki_FAQ#When_I_try_to_upload_files_in_Mediawiki_1.5_I_always_get_a_.22The_file_is_corrupt_or_has_an_incorrect_extension._Please_check_the_file_and_upload_again..22_error. and http://meta.wikimedia.org/wiki/Uploading_files#The_file_is_corrupt_or_has_an_incorrect_extension._Please_check_the_file_and_upload_again. To troubleshooot I'd temporarily set $wgVerifyMimeType = false; in LocalSettings.php That did not help. I've explicitly set $wgFileExtensions = array('gif','png','jpg','jpeg'); in LocalSettings.php That did not help. The directory permissions are chmod -rwx for owner and group, but nothing for others. I've asked in #mediawiki about this issue, verified a few test files were not corrupt using the program xv (which they said was good at verifying the validity of a file). Still I get these errors. I've doublechecked the Whitelist and Blacklist in DefaultSettings.php I'm really out of ideas.
Confirmed on your system. Can you check if PHP's 'open_basedir' option is on? This usually makes it impossible for the program to open the file and check it for validity before saving it.
Thank you for responding. I checked up on a few things tonight with our web host. I double checked to make sure that our upload directory was writable by the web server and it was not. He set it to be writable by the web server though, so that should be corrected now. I was incorrectly assuming that before. I also had him check on php's 'open_basedir' option. We cannot turn the 'open_basedir' restrictions off because we are not the only site on that box. So, from this point... I thought to myself, well as long as the upload directory is writable by webserver, uploads should work as long as all file checks are off. I would not plan to leave it this way, because of security issues but I wanted to troubleshoot so I set all these things in LocalSettings.php: $wgVerifyMimeType = false; $wgStrictFileExtensions = false; $wgCheckFileExtensions = false; I would assume now that all checks on the file are off, and as long as the upload directory is correctly writable by the web server it should have worked. No such luck. When doing my upload tests I made sure to log out of my account, log back in and throw a ?action:purge in the URL before the upload just to make sure the cache and was cleared and things. Are there any other things I can try, or because of our situation with the web server and 'open_basedir' needing to be left on, am I out of luck? Thank you for what you've done already though. Additional Info: PHP (http://www.php.net/): 4.3.10-16 (apache2handler)
MediaWiki does security checks on uploaded files to prevent files being uploaded that would trigger HTML autodetection in Internet Explorer. This could be used as a cross-site scripting vector to hijack accounts on the wiki. With PHP's ham-handed open_basedir on, unfortunately, the file can't be examined while it's still in the system temporary directory. If you hack up the code in SpecialUpload.php, you could perhaps disable this (not recommended, as it opens your users to the IE exploit) or move the files to a temporary directory first. (If you do so, you may wish to carefully lock down that directory from web access.)
My web host adjusted some things to accomidate for us. Every second level user on the box now runs under its own user, even php-scripts. Many link use a URL scheme wich only work, if php is used as apache.module: index.php/foo/bar. In cgi-mode this doesn't work. But he fixed this issus with a rewrite rule defined in /var/www/yoper.com/www/wiki/.htaccess. This redirects accesses to index.php/foo/bar to index.php?title=foo/bar transparently. So my problem is now solved, thank you for helping narrow down the specific problem. I wish there was a nice way for me to add this into the FAQ... hrm I'll think about a way to generalize and account for this info there, as there's nothing along these lines there currently. This incident can be closed.
