Julio Biason wrote:
On 23/12/05, Chris Smith <chris@xxxxxxxxxxxxx> wrote:I see what you mean, I missed that before. Perhaps you should file a bug report (or post Andi a patch). The whole restriction is kind of odd, since there is no check done anywhere on the file contents, maybe it does make sense to have a restriction on what the wiki offers for download to its visitors rather than what contributors are capable of uploading. The server can't be hurt by uploading (at least not if permissions and .htaccess are set correctly) but potentially visitors could be hurt by downloading an executable file. Under those circumstances it does make sense to restrict the filenames used for uploads. I realise the message isn't configured that way and I don't know what was in Andi's (or the author's) mind when they wrote that code...
Does dokuwiki get to see the name the file had on the client machine?
The $_FILES data only includes one file name from the client, 'name',
and that is what dokuwiki uses.
Ok, maybe I got a little bit lost here, but I tried to upload another file, removing the extension again and adding some output while uploading. I got the following from $_FILES (printing key/value):
name = bzr-0.6.2.tar.gz type = application/x-gzip tmp_name = /tmp/phpTPJTEB error = 0 size = 519926
(Just a note: the id/wikiname used was "bzr-0.6.2")
So, yeah, $_FILES['name'] really got the real name. The problem seems to be the code around line 113, where DokuWiki uses the 'id' as filename instead of $_FILES['name']. If you leave it blank, the PHP will use the name as id and work.
If I'm not mistaken, the solution is just change
$fn = mediaFN($id);
to
$fn = mediaFN($_FILES["name"]);
--
Julio Biason <julio.biason@xxxxxxxxx>
-- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist
