PmWiki has a feature script called upload.php
that allows users to upload files to the wiki server from a web browser. These files can then be easily accessed using markup within wiki pages. This page describes how to install and configure the upload feature.
Some notes about security
- Keep in mind that letting users (anonymously!) upload files to your web server does entail some amount of risk. The
upload.php
script has been designed to reduce the hazards, but Wiki Administrators should be aware that the potential for vulnerabilities exist, and that misconfiguration of the upload utility could lead to unwanted consequences.
- By default, authorized users are able to overwrite files that have already been uploaded, without the possibility of restoring the previous version of the file. If you want to disallow users from being able to overwrite files that have already been uploaded, add the following line to config.php:
$EnableUploadOverwrite = 0;
Basic installation
The upload.php script is automatically included from stdconfig.php if the $EnableUpload
variable is true in config.php. In addition, config.php can set the $UploadDir
and $UploadUrlFmt
variables to specify the local directory where uploaded files should be stored, and the URL that can be used to access that directory. By default, $UploadDir
and $UploadUrlFmt
assume that uploads will be stored in a directory called uploads/ within the current directory (usually the one containing pmwiki.php). In addition, config.php should also set a default upload password (see PasswordsAdmin).
Thus, a basic config.php for uploads might look like:
<?php
$EnableUpload
= 1;
$UploadDir
= "/home/john/public_html/uploads";
$UploadUrlFmt
= "http://www.john.com/~john/uploads";
$DefaultPasswords['upload'] = crypt('mysecret');
## more configuration entries here...
?>
The Upload directory
For the upload feature to work properly, the directory given by $UploadDir must be writable by the web server process, and it must be in a location that is accessible to the web somewhere (e.g., in a subdirectory of public_html). Executing PmWiki with uploads enabled will prompt you with the set of steps required to create the uploads directory on your server (it differs from one server to the next).
Uploading a file
Once the upload feature is enabled, users can access the upload form by adding "?action=upload
" to the end of a normal PmWiki URL. The user will be prompted for an upload password similar to the way other pages ask for passwords (see Passwords and PasswordsAdmin for information about setting passwords on pages, groups, and the entire site).
Another way to access the upload form to insert the markup "Attach:filename.ext
" into an existing page, where filename.ext
is the name of a new file to be uploaded. When the page is displayed, a '?-link' will be added to the end of the markup to take the author to the upload page.
By default, PmWiki will organize the uploaded files into separate subdirectories for each group. This can be changed by modifying the $UploadPrefixFmt
variable. See Cookbook:UploadGroups for details.
Restricting uploaded files for groups and pages
Uploads can be enabled only for specific groups or pages by using a per group customization. Simply set $EnableUpload
=1;
for those groups or pages where uploading is to be enabled; alternately, set $EnableUpload
=1;
in the config.php file and then set $EnableUpload
=0;
in the per-group or per-page customization files where uploads are to be disabled.
Restricting uploaded files type and size
The upload script performs a number of verifications on an uploaded file before storing it in the upload directory. The basic verifications are described below.
- filenames
- the name for the uploaded file can contain only letters, digits, underscores, hyphens, spaces, and periods, and the name must begin and end with a letter or digit.
- file extension
- only files with approved extensions such as "
.gif
", ".jpeg
", ".doc
", etc. are allowed to be uploaded to the web server. This is vitally important for server security, since the web server might attempt to execute or specially process files with extensions like ".php
", ".cgi
", etc.
- file size
- By default all uploads are limited to 50K bytes, as specified by the $UploadMaxSize variable. Thus, to limit all uploads to 100K, simply specify a new value for $UploadMaxSize in config.php:
$UploadMaxSize = 100000;
However, maximum file sizes can also be specified for each type of file uploaded. Thus, an administrator can restrict ".gif
" and ".jpeg
" files to 20K, ".doc
" files to 200K, and all others to the size given by $UploadMaxSize. The $UploadExtSize array is used to determine which file extensions are valid and the maximum upload size (in bytes) for each file type. For example:
$UploadExtSize['gif'] = 20000; # limit .gif files to 20K
Setting an entry to zero disables file uploads of that type altogether:
$UploadExtSize['zip'] = 0; # disallow .zip files
Adding new filetypes to permitted uploads
To add a new extension to the list of allowed upload types, add a line like the following to a local customization file:
$UploadExts['ext'] = 'content-type';
where ext is the extension to be added, and content-type is the content-type (MIME type) to be used for files with that extension. For example, to add the 'dxf
' extension with a Content-Type of 'image/x-dxf
', place the line
$UploadExts['dxf'] = 'image/x-dxf';
Other file size limits
There are other factors involved that affect upload file sizes. In Apache 2.0, there is a LimitRequestBody directive that controls the maximum size of anything that is posted (including file uploads). Apache has this defaulted to unlimited size. However, some Linux distributions (e.g., Red Hat Linux) limit postings to 512K so this may need to be changed or increased. (Normally these settings are in an httpd.conf configuration file or in a file in /etc/httpd/conf.d.)
Problem noted on Red Hat 8.0/9.0 with Apache 2.0.x, the error "Requested content-length of 670955 is larger than the configured limit of 524288" was occuring under Apache and a "Page not found" would appear in the browser. Trying the above settings made no change with PHP, but on Red Hat 8.0/9.0 there is an additional PHP config file, /etc/httpd/conf.d/php.conf, and increasing the number on the line "LimitRequestBody 524288" solves the issue.
PHP itself has two limits on file uploads (usually located in /etc/php.ini). The first is the upload_max_filesize
parameter, which is set to 2M by default. The second is post_max_size
, which is set to 6M by default.
With the variables in place--PmWiki's maximum file size, Apache's request-size limits, and the PHP file size parameters, the maximum uploaded file size will be the smallest of the three variables.
Password protecting uploaded files
Setting a read password for pages (and groups) will prevent an attached file to be seen or accessed through the page, but to prevent direct access to the file location (the uploads/ directory) one can do the following:
- In local/config.php set
$EnableDirectDownload
=0;
- Deny public access to the uploads/ directory through moving it out of the html/ or public_html/ directory tree, or through a .htacces file.
See Cookbook:SecureAttachments.
Category.DocumentationToDo?
Issues
- For optimal use of BibtexRef?, the ability to upload "
.bib
" files is necessary. Can this be added to the list of permitted extensions? [RickL]
- Can't the BibtexRef? just add the permitted extension rather than requiring it in the core...? --Pm?
- I've added this to my slight modification of BibtexRef? - see the very bottom of the page. -- Rob
- Incomplete documentation - give example how to do this properly in a local / config.php file (Monty?)
- the Star Office aka Open Office org extension are not in the core; I recommend they be added. (Monty?)
Hmmm, what are the open office mime types? --Pm?
Other notes
- Note that read access to uploaded files is not controlled by any of the page or group attributes--uploaded files are accessible even if pages are protected by read passwords.
- Is there likely to be any solution to this? Francis?
- The ability to password-protect uploads is now available in 2.0.beta31. Set
$EnableDirectDownload
=0; in the local/config.php file, and deny public access to the uploads/ directory through moving it out of the html/ or public_html/ directory tree, or through a .htacces file. See Cookbook:SecureAttachments. --HansB?
- If uploads doesn't seem to work, make sure that your PHP installation allows uploads. The php.ini file (usually /etc/php.ini or /usr/local/lib/php.ini) should have
file_uploads = On
Note that if you change this value, httpd must generally be restarted. Another way to check if uploads are allowed by the server is to set $EnableDiag to 1 in config.php, and set ?action=phpinfo on a URL. The "file_uploads
" variable must have a value of 1 (if it says "no value
", that means it's off).
for some reason setting a password for uploads in config file is causing upload operation to fail all the time, it does not matter if it is plain password or encrypted one.
but if i set empty password as this one
$DefaultPasswords['upload'] = '';
i can upload without any problem. But it seems like setting a password per page does work for uploads, rather than doing it in config file
if anyone has a solution for this please let me know. i am not sure about the version of pmwiki but i have downloaded one month ago.
thnx
gecicigec@fastmail.fm
- same here with the most up-to-date version (date: 04-26-2005) i had to set the password to '' without the line or with a set password it did not work
I too saw some weird behavior with the upload password. Even though I had no `$DefaultPasswords['upload']
line in local/config.php, I was still asked for a password every time I tried to upload a file. The solution was to set my upload password to '' as the user above mentioned.
I then found that when I uploaded a particular file pmwiki would report that a file was there. However, on inspection the file size was 0 bytes. The culprit this time was that my /etc/php.ini had an upload_maxfilesize
of 2M, and the file I was uploading was 6MB is size. This caused pmwiki's upload to appear to work,but it just created the 0 byte file. I increased the upload_maxfilesize to 10MB and restarted apache. Then everything worked fine.
So in summary, even if you set your local/config.php to allow larger files, the upload will fail silently if your php upload_maxfilesize setting is too small.
Phil Hollenback 4/5/05
Pm wrote the following in a
message to the pmwiki-users list:
Each entry in $UploadExts needs to be the extension and the
mime-type associated with that extension, thus:
$UploadExts = array(
'gif' => 'image/gif',
'jpeg' => 'image/jpeg',
'jpg' => 'image/jpeg',
'png' => 'image/png',
# ...
)
For the types that PmWiki already knows about it's not necessary
to repeat them here (the upload.php script adds PmWiki's defaults
to whatever the admin supplies).
Category: Uploads
<< Passwords administration | PmWiki.Documentation Index | Internationalizations >>