[pmwiki-users] Read-protecting Site.*

[ThomasP]

> 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?
>

Agree with Tegan. This was also my first thought once I came across the
issue some months ago (in connection with the IncludeFile recipe), and I
can only repeat what Tegan said in other words:

What the engine performs on most of these special pages is not actually a
'read', but rather an 'interpret' operation, which is worth distinguishing
in many occasions. (For example it is a difference, whether you may read a
notify list page, or whether it may be interpreted for you.) This
concerns, as Tegan said also page inclusions, but also for example
interpretation of internationalization pages (and more might come).

Usually one would say that in the end all possible interpretations will be
allowed, so why make a fuss (or more correctly: an extra action) about it.
But "vicious minds" can also imagine cases where even the interpretation
itself should be controlled page-wise via the standard authorization
scheme (instead of only config.php tweaks). In any case in the long run it
is IMHF the more systematic approach.

ThomasP

IMHF = in my humble feeling