[pmwiki-users] pmwiki-2.0.beta31 released
Patrick R. Michaud
pmichaud at pobox.com
Fri Apr 15 15:40:42 CDT 2005
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.
More information about the pmwiki-users