Last modified: 2014-11-13 13:01:57 UTC
Intention: Upgrade some wikies to 1.23.0, some of them are 10 years old Steps to Reproduce: 1. Make a new wiki 2. In apache, alias image dir to img_auth.php 3. Upload a picture with extension .PNG 4. Try to view picture when logged in. .png will work, .PNG won't. Actual Results: Apache give a 403 error with the following text: Forbidden Invalid file extension found in the path info or query string. Expected Results: The picture. Reproducible: Always In includes/libs/IEUrlExtension.php at line 120, the following line seems to be the problem: if ( !preg_match( '/^[a-zA-Z0-9_-]+$/', $extension ) ) { I believe the '!' should be removed. This seems to be a fallback check for correct extensions that instead of accepting normal alphanumerical extensions instead accepts all non-alphanumerical extensions.
With which browser(s) was this tested? I also wonder if adding image/png PNG to mime.types would change anything; see https://www.mediawiki.org/wiki/Manual:MIME_type_detection#MIME_type_validation (In reply to vidarsk from comment #0) > 4. Try to view picture when logged in. .png will work, .PNG won't. So they just don't load in the browser? Or is there an error?
Tested in FireFox. I doubt mime.types would help, unless there's some magic there that causes it to skip the parameter test in IEUrlExtension.php. When I try to open the picture in FireFox I see the following: Apache give a 403 error with the following text: Forbidden Invalid file extension found in the path info or query string.
Mime.types wouldnt affect this
This is still a problem on 1.23.2.
This happens also on other browsers I test with IE11, IE8 and Firefox 31 . This happens also with other fileextensions like jpg and JPG. This happens also with other webservers (IIS6) in my case. There is an example on https://aquanautweb.de/testwiki/index.php?title=Broken_Filelinks This is a wide regression on existing wikis that already have a large number of uppercased extended files within.
Removing the ! in includes/libs/IEUrlExtension.php at line 120 brings the files back in all cases mentioned in Comment 5
Can confirm bug in mediawiki 1.23.3 and yes, the logic behind that preg_match is definitely false.
We also experienced this bug after upgrading a wiki from 1.13.2 to 1.23.1. Following the suggestion above ("Removing the ! in includes/libs/IEUrlExtension.php at line 120") fixed the problem for us.
