PmWiki takes a somewhat, but justifiable, paranoid stance
when it comes to the uploads feature. Thus, the default settings for
uploads tend to try to restrict the feature as much as possible:
This way the potential damage is limited until/unless the wiki
administrator explicitly relaxes the restrictions.
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:
If you have edit passwords and wish to allow all users with edit rights to upload, instead of $DefaultPasswords
['upload'], you can set $HandleAuth
['upload'] = 'edit';
in config.php.
You may also need to explicitly set which filesystem directory will hold uploads and provide a URL that corresponds to that directory like:
You may prefer uploads attached per-page rather than per-group or per-site if you plan to have many files attached to individual pages. This setting simplifies the management of picture galleries for example. (In a page, you can always link to attachments to other pages.)
For the upload feature to work properly, the directory given by $UploadDir must be writable by the web server process, and it usually 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). Note that you are likely to be required to explicitly create writable group- or page-specific subdirectories as well!
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.
PmWiki does not manage versioning of uploaded files by default. However, by setting $EnableUploadVersions
=1; an administrator can have older versions of uploads preserved in the uploads directory along with the most recent version.
Uploads can be restricted to an overall size limit for groups. In the group configuration file (i.e., local/Group.php), add the line
This will limit the total size of uploads for that group to 1000KB --any upload that pushes the total over the limit will be rejected with an error message. This value defaults to zero (unlimited).
Uploads can also be restricted to an overall size limit for all uploads. Add the line
This will limit the total size of uploads for the whole wiki to 10000KB --any upload that pushes the total over the limit will be rejected with an error message. This value defaults to zero (unlimited).
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.
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:
You can limit which types of files are uploadable by disabling all defaults and specifying only desired types
Setting the variable $UploadMax to zero will disable all default file types. Individual file types may then be enabled by setting their maximum size with the variable $UploadExtSize.
To add a new extension to the list of allowed upload types, add a line like the following to a local customization file:
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',
'xxx' => 'yyyy/zzz'
);
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 administrator supplies).
See also Cookbook:UploadTypes for additional types.
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 occurring 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.
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.
Setting a read password for pages (and groups) will prevent an attached file from being seen or accessed through the page, but to prevent direct access to the file location (the uploads/ directory) one can do the following:
Note that if you change this values, 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).