[pmwiki-users] pmwiki-2.0.beta31 released

[Patrick R. Michaud]

On Fri, Apr 15, 2005 at 09:19:59PM +0100, Hans wrote:
> Friday, April 15, 2005, 8:56:21 PM, Patrick wrote:
> > However, a big disadvantage is that all attachments are publicly 
> > accessible as long as someone knows the URL.
> 
> Do I understand this right that default attachments are publicly
> accessible even though the page or group is read-password protected?

Yes, it's always been this way.  See PITS:00109.

> > 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
> 
> So ?action=download gets used automatically if
> $EnableDirectDownload=0, and there is no need to use it manually in
> links inside pages? Just use normal Attach:filename markup syntax?

Yes.  $EnableDirectDownload changes what Attach:filename generates.

> > This provides some important features:
> >   - it allows PmWiki to use site/group/page permissions to control
> >     access to attachments
> 
> So now a page or group read-password will protect the attachments of
> the page and group?

It can, if the admin takes whatever other steps are needed to
protect the uploads/ directory (see my previous message).

> >   - it means the uploads/ directory no longer needs to be web accessible
> >     and can be anywhere in the filesystem
> 
> How does this work? How does the Attach:filename markup work?
> $UploadUrlFmt could have been pointing anywhere in the filesystem, so
> what is the difference?

At the moment, Attach:filename looks at $EnableDirectDownload to
determine if it should generate a link based on $UploadUrlFmt or
based on ?action=download.  I may change this so that it always
uses $UploadUrlFmt, and the value of $UploadUrlFmt changes depending
on the setting of $EnableDirectDownload (I haven't decided yet).

> >   - 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)
> 
> And how does that work?

Well, since with ?action=download PmWiki is taking the place of
the webserver, it has to generate the Content-Type: header that the
webserver would've normally done.  PmWiki does this via the
$UploadExts array.  Thus, if an admin wants .php attachments to
display as text, he sets

    $UploadExts['php'] = 'text/plain';

Similarly, for an OpenOffice .sxw document:

    $UploadExts['sxw'] = 'application/vnd.sun.xml.writer';

And if the admin wants to configure Microsoft word documents to
download instead of being automatically opened within IE:

    $UploadExts['doc'] = 'application/octet-stream';

> Forgive me all these questions, I do wish to understand, it seems
> quite important.

Questions are always welcome here.

Pm