[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