[pmwiki-users] pmwiki-2.0.beta31 released

[Patrick R. Michaud]

On Fri, Apr 15, 2005 at 08:21:20PM +0100, Hans wrote:
> Friday, April 15, 2005, 8:06:50 AM, Patrick wrote:
> > 2.0.beta31 adds the ability to store and serve attachments (uploads)
> > from directories that are not directly accessible to the webserver.
> > A new "download" action ([@?action=download@]) tells PmWiki to retrieve
> > an attachment associated with the current page.  This can be used for
> > protecting attachments via a page's passwords, or for working around
> > webservers that cannot access files in PmWiki's ''uploads/'' directories.
> 
> > Setting $EnableDirectDownload=0; tells PmWiki to use [@?action=download@]
> > links to retrieve attachments instead of telling the browser to access
> > the attachments directly through the webserver.  Note that this
> > setting by itself may not be enough to protect uploads; one may need
> > also need to to configure the webserver or ''uploads/'' directory
> > to block direct requests to the webserver for attachment files.
> > More on this in another message or cookbook recipe (or write me
> > for details).
> 
> I must confess total puzzlement as to how to use the above in
> practical terms.

Reasonable -- it was very late when I wrote the above, and I'm not
entirely sure how best to explain it anyway.  But I'll try again here.

By default when PmWiki generates "Attach:" links, it creates them as 
"direct" links into the webserver directory.  For example, in the 
Cookbook the markup "Attach:gemini.zip" is converted to a link to 
http://www.pmwiki.org/pmwiki/uploads/Cookbook/gemini.zip.
Note that when followed this link will completely bypass the pmwiki.php
script, and act as though you were accessing any "normal" file
on the webserver.

This has some advantages and disadvantages.  The biggest advantage is 
that it's fast, in that the webserver doesn't have to execute a PHP
script in order to return the appropriate file to the browser.  The
webserver can also take care of determining the appropriate Content-Type
for the file.

However, a big disadvantage is that all attachments are publicly 
accessible as long as someone knows the URL.  In addition, there are
some environments (examples include IIS and sourceforge.net) where the
webserver disallows direct access to files that have been created
by a PHP script.

As a result, beta31 now offers an ?action=download option, which can be used 
to retrieve a page's attachment.  For example, with $EnableDirectDownload 
set to zero, PmWiki will convert the "Attach:gemini.zip" markup into 
http://www.pmwiki.org/wiki/Cookbook/GeminiSkin?action=download&upname=gemini.zip

This provides some important features:
  - it allows PmWiki to use site/group/page permissions to control
    access to attachments
  - it means the uploads/ directory no longer needs to be web accessible
    and can be anywhere in the filesystem
  - the file's Content-Type and semantics can be controlled by PmWiki
    which may be easier to configure (e.g., it makes it easier for .php
    attachments to be downloaded instead of executed on the server)
Of course, the downside of this is that accessing an attachment
a somewhat heavier load on the server, since it now involves 
running a PHP script and determining the page's permissions before
the file can be transmitted.

Still, for sites that want to use PmWiki's authorization system to
restrict access to attachments, or that are on webservers that disallow
accessing the attachments directly, this is an incredibly useful feature
and the trade-offs in performance isn't important.

Does that help?

Pm