Last modified: 2012-01-30 15:44:58 UTC
In img_auth.php, $path is being set to a value that includes 'img_auth.php' at the beginning of it. Setting $path = $_SERVER['PATH_INFO']; fixed the problem and made everything work correctly, but it appears that somehow what is being returned in WebRequest::getPathInfo() and stored in $matches['title'] includes the script filename at the beginning. This issue happens on a DreamHost shared server.
(In reply to comment #0) > In img_auth.php, $path is being set to a value that includes 'img_auth.php' at > the beginning of it. What value does it get set to?
(In reply to comment #1) > What value does it get set to? Adding a couple debugging lines to img_auth.php@45112b89 (I use the GitHub mirror) dated 2011-11-20, I get: $matches = Array ( [title] => img_auth.php/a/ab/File_name.ext ) 1 $path = img_auth.php/a/ab/File_name.ext The extra bit at the beginning makes the realpath() call on Line 71 return false (see https://github.com/mediawiki/mediawiki-trunk-phase3/blob/797386c6fa75a3c4d239c8ebcd2f6c796f512f8e/img_auth.php#L71 ) That in turn makes $filename = '' (empty) and so the directory traversal check on L75 fails. This is all because WebRequest::getPathInfo() is returning the filename of the calling script along with the actual PATH_INFO data. Hope that helps. I don't really understand WebRequest too well, and I don't have time to dig until later this week.
By any chance is your $wgArticlePath set to "/$1"? If so, and you're accessing urls like "http://wiki.example.com/img_auth.php/a/ab/File_name.ext" then it sounds like MediaWiki is interpreting that url as an article path since the script you're using is not index.php. We may want to add handling that will intelligently understand what the real .php file being referenced in the URL is and make use of that instead of ONLY checking for $wgScript. If not auto-detection then maybe we should add a $wg variable that lists all known php script paths. Then we can add img_auth.php and api.php to it, users who do things like i.php can add both to it, and extensions that define new .php files can add theirs as well in case.
(In reply to comment #3) > By any chance is your $wgArticlePath set to "/$1"? Yes, it is. The relevant config block: $wgScriptPath = ""; $wgScriptExtension = ".php"; $wgScript = "$wgScriptPath/index.php"; $wgArticlePath = "/$1"; I don't remember having this problem the last time I set up a personal wiki site, but then again that was with version 1.11 or so. (I was also using a stable release, instead of checking out the latest development version every so often.) Current .htaccess: RewriteEngine on RewriteCond %{REQUEST_FILENAME} !\.[a-z]{2,4}$ [OR] RewriteCond %{REQUEST_FILENAME} [:] RewriteCond %{REQUEST_FILENAME} !^(index|img_auth|api)\.php RewriteRule (.*) index.php?title=$1 [NC] Is there a different .htaccess configuration that will avoid this issue? (I'd rather that than keep rewriting img_auth.php) > We may want to add handling that will intelligently understand what the real > .php file being referenced in the URL is and make use of that instead of ONLY > checking for $wgScript. If not auto-detection then maybe we should add a $wg > variable that lists all known php script paths. Then we can add img_auth.php > and api.php to it, users who do things like i.php can add both to it, and > extensions that define new .php files can add theirs as well in case. That sounds like a good idea in theory, but wouldn't it have the potential for causing problems if someone wants a page in NS_MAIN that has the same name as a core file listed in that array?
(In reply to comment #4) > (In reply to comment #3) > > By any chance is your $wgArticlePath set to "/$1"? > > Yes, it is. The relevant config block: > > $wgScriptPath = ""; > $wgScriptExtension = ".php"; > $wgScript = "$wgScriptPath/index.php"; > $wgArticlePath = "/$1"; > > I don't remember having this problem the last time I set up a personal wiki > site, but then again that was with version 1.11 or so. (I was also using a > stable release, instead of checking out the latest development version every so > often.) > > Current .htaccess: > > RewriteEngine on > RewriteCond %{REQUEST_FILENAME} !\.[a-z]{2,4}$ [OR] > RewriteCond %{REQUEST_FILENAME} [:] > RewriteCond %{REQUEST_FILENAME} !^(index|img_auth|api)\.php > RewriteRule (.*) index.php?title=$1 [NC] > > Is there a different .htaccess configuration that will avoid this issue? (I'd > rather that than keep rewriting img_auth.php) > > > We may want to add handling that will intelligently understand what the real > > .php file being referenced in the URL is and make use of that instead of ONLY > > checking for $wgScript. If not auto-detection then maybe we should add a $wg > > variable that lists all known php script paths. Then we can add img_auth.php > > and api.php to it, users who do things like i.php can add both to it, and > > extensions that define new .php files can add theirs as well in case. > > That sounds like a good idea in theory, but wouldn't it have the potential for > causing problems if someone wants a page in NS_MAIN that has the same name as a > core file listed in that array? :/ Your config better not be serving [[Api.php]] for /api.php
(In reply to comment #5) > :/ Your config better not be serving [[Api.php]] for /api.php Nope. :) http://wiki.technobabbl.es/api.php
I committed some changes to the WebRequest and img_auth.php handling code in r104150. Could you tell me if that change fixes this bug?
Tested and found to be behaving on my test wiki. Appears fixed by r104150
*** Bug 34042 has been marked as a duplicate of this bug. ***
