[pmwiki-users] Images in another group

[Patrick R. Michaud]

On Wed, Dec 07, 2005 at 01:35:59PM -0600, Tegan Dowling wrote:
> On 12/1/05, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> >    On the other hand, I suppose that we could redefine the Attach:
> >    markup so that Attach:XYZ/image.ext refers to page XYZ in the
> >    current group if such a page exists, otherwise it refers to the
> >    group XYZ.  This would mean we can no longer describe Attach:
> >    in terms of existing markup semantics as we do now, but it might
> >    be more in line with what authors seem to naturally expect.
>
>    One consideration, in contemplating any change to how this works, 
>    would be the implications of a change for secure attachments, per
>    http://www.pmwiki.org/wiki/Cookbook/SecureAttachments.

It wouldn't have any effect on it.  The security of an attachment
doesn't depend on the form of the markup or urls that are generated 
(via the Attach: markup), it depends solely on whatever handles the
incoming url requests for the uploaded files.

>    I think that I always assumed (oops) that read-protection of a group
>    automatically extended to the group's uploads.  Now I'm trying to make
>    sure that I fully grasp how this option works, so that I can make my wikis
>    function the way I always thought they already did.

Setting $EnableDirectDownload=0; and securing the uploads/ directory
will do what you want here -- access to any uploads will depend upon
the browser having read access to the associated page.

>    (BTW: could Secure Attachments (the version in which the special .htaccess
>    file is included in the uploads directory) be considered for the core
>    distribution?)
> 
>    (And also btw: In any case, does the explanatory material in
>    Cookbook/SecureAttachments actually belong in the PmWiki wikigroup, since
>    there's really no recipe involved?)

"Recipe" doesn't always mean "downloadable script" -- sometimes it's just
a set of directions to take to configure PmWiki in a certain manner.  But
yes, perhaps SecureAttachments belongs in the PmWiki docs.

>    To bring this post back around to the subject of this thread: am I right
>    in now understanding that even using the SecureAttachment procedure, there
>    is no mechanism for making the read-protection of a page extend to a file
>    that's uploaded to that page? That even though the point of this thread is
>    that /references/ to uploads are done via references to pages, not to
>    wikigroups, that's not the same as saying that the uploads themselves are
>    associated with specific pages?

I don't think the above understanding is correct -- I'll try to
summarize here what really happens:  
  * As far as PmWiki is concerned, uploads are *always* associated 
    with specific pages (i.e., uploads are really "attachments").
  * PmWiki's default configuration has all of the pages in a wikigroup
    sharing the same set of attachments.  While most people think of the
    attachments as belonging to the "group", the reality is that in
    this configuration uploads are effectively attached to every 
    page in the group, and not to the group itself.
  * There are two ways that a browser can access an attachment.  One 
    is by direct url (http://www.example.com/pmwiki/uploads/Group/file.ext)
    and the other is by using ?action=download on a page 
    (.../pmwiki/pmwiki.php/Group/Page?action=download&upname=file.ext).
  * Access to attachments via ?action=download requires read permissions
    on the associated page.
  * Access to attachments via direct urls depends on the webserver
    settings.
  * Setting $EnableDirectDownload=0; causes the Attach: markup to 
    generate urls using ?action=download, otherwise direct urls are
    used.

Thus, if the wiki administrator turns off access to uploads via
direct url (e.g., via a .htaccess file or equivalent), then the only
way to access uploaded files will be by using ?action=download on a 
page, and this will require read permission to the page.  

Hope this helps...?

Pm