[pmwiki-users] Read-protecting Site.*

Patrick R. Michaud pmichaud at pobox.com
Thu Apr 12 13:23:25 CDT 2007


On Thu, Apr 12, 2007 at 12:32:14PM -0500, Tegan Dowling wrote:
> On 4/12/07, Tegan Dowling <tmdowling at gmail.com> wrote:
> > Taking another step slightly sideways:  Several of these are pages
> > that no one but administrators ever need to actually browse.  The wiki
> > itself needs access to them in order to perform some functions on
> > behalf of non-admin or even non-passworded users of the site, but
> > neither those users nor the wiki actually **browses** the pages.
> > Could there be another passwordable attribute "access" or something
> > like that?

In general I'm fairly opposed to adding additional password 
attributes like this, because I fear it complicates an already
very complex system even further.  

> Looks like I didn't make myself clear (again).  This would be like the
> read attribute, in the sense that it would allow the wiki itself to
> access the page provided the user met whatever criteria are specified
> (so it could be @nopass), but it would let the admin set the actual
> read attribute to @admin, or @_site_edit, or whatever.

The real issue here is one of distinguishing between "the wiki 
accesses the page" and "the user accesses the page", because in
practice it's very difficult to distinguish the two cases.  Reviewing
my original list:

Site.PageActions, Site.SideBar:
    This normally comes from the <!--wiki:...--> directive in skin
    templates, which by default honors any read permissions given on
    the listed pages.  There *is* a <!--page:...--> version of the
    directive that renders a page even if it's read protected, but
    very few templates are actually using this.  And in the case of
    Site.SideBar, there's probably a very good case to be made that
    the <!--wiki:...--> directive used in the template for sidebar
    pages really should honor any read restrictions that exist for
    the sidebar pages (e.g., it shouldn't clear the way to reading
    a Group.SideBar page in a read-protected group).
 
Site.PageListTemplates, Site.LocalTemplates:
    This is generally used with the fmt= parameter for (:pagelist:), as
    in 'fmt=#bytitle' or 'fmt=#bygroup'.  However, we don't want (:pagelist:)
    itself to be able to bypass permissions completely, because authors 
    can also write 'fmt=SomeOtherPage', and in that case we need to verify
    that the browser is authorized to view SomeOtherPage (because its
    contents will appear in the output).  

    I've been toying with the idea that fmt=#section could bypass read
    permissions, since that syntax limits the result to the current
    page or to a set of known pages as configured by the script/administrator
    anyway.

Site.EditQuickReference, Site.UploadQuickReference, Site.PageNotFound:
    These pages are included by an (:include:) markup (or its programmatic
    equivalent) from several sources.  Site.EditQuickReference comes from
    an (:include:) markup within Site.EditForm.  Site.UploadQuickReference
    currently comes from an internal directive, but I expect it will
    eventually be coming from (:include:) within a Site.UploadForm page.
    Site.PageNotFound is generated by an (:include:) from within
    $DefaultPageTextFmt .

    It's pretty clear that we don't want the (:include:) directive to
    be able to bypass read permissions in the general case, because then
    any author could use it to bypass read permissions.  So, we'd have
    to come up with a way for (:include:) to bypass read permissions
    only in certain situations.  And I think that any approach we take here
    ends up being either exactly equivalent to setting '@nopass' on the
    relevant pages, or opens sites up to plenty of unanticipated avenues
    for exploiting the bypass to view other read-protected pages.


> One way it might get used would be with via includes - I can create a
> page with several chunks of boilerplate text, for instance, and use
> [[#anchor]] tags to set them off from one another.  This page might
> have read-attribute of @_site_edit, but access-attribute of @nopass.
> Now I can include a section from this page in any unprotected page,
> and regular, un-passworded visitors to the site can read the included
> bits there, but can't find or read the source page itself.

Something like this could work, but I don't see any major advantage to
this over simply using '@nopass' as the read password for the page.
Yes, it would mean that could have pages that could be read via an
include directive but not browsed directly, but the fact that visitors
can browse these pages isn't really an issue.  What we want to be
able to do is protect the _other_ Site.* pages from being browsed,
while preserving the site's ability to access these "system" pages,
and '@nopass' or something like it seems to do exactly that.

> And of course, as with nearly all such things, it would be an admin's
> option whether to even use the new attribute.

Anytime we say "something is an admin's option" it also implies that
admins can somehow be aware of the option, and that they understand
how it fits into the overall system.  That's where complexity increases,
and for the rare cases where an admin wants to deviate from the norm,
we have other mechanisms already available to achieve this.

Thanks!

Pm



More information about the pmwiki-users mailing list