[pmwiki-users] Read-protecting Site.*

[Tegan Dowling]

On 4/12/07, Tegan Dowling <tmdowling at gmail.com> wrote:
> On 4/12/07, Ben Wilson <dausha at gmail.com> wrote:
> > On 4/12/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > [...]
> >
> > > Administrators often want to restrict browse access to pages
> > > in the Site.* group.  The natural (and obvious) approach is
> > > to place a read password on Site.GroupAttributes, but that's
> > > often problematic because some pages in Site.* need read
> > > access in order to work properly.  These pages include:
> > >
> > [...]
> > >
> > > So, I'm thinking that perhaps the cleanest approach would be
> > > to add special read passwords (similar to '@nopass') to the above
> > > so that they can be accessed even when the Site group is
> > > read protected.
> > >
> > > Thoughts?
> >
> > Funny you should mention that. I just deployed a wiki that is private
> > except for Main.*, and had to go to just those pages to @nopass. If I
> > had any influence with the wonderful development effort of PmWiki
> > (waves two pennies seductively) I would suggest @nopass by default for
> > those site pages. :-)
> >
> > In the alternative, could an administrator set up a list of @nopass
> > pages in local/config.php? That could prevent somebody from
> > accidentally restricting critical pages.
>
> 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?

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.

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.

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