[pmwiki-users] Site.* permissions (was: Displaying page permissions)

ThomasP pmwikidev at sigproc.de
Sun May 27 01:40:57 CDT 2007


On Sat, May 26, 2007 16:06, Patrick R. Michaud wrote:
> In fact, this brings up a larger question of what to do with the
> Site.* group in general... should we change the PmWiki default so that
> viewing pages in the Site group is restricted to admins?  There
> are three options that I see:
>
>
> Option 1:  Lock the Site.* group to be read only by admins, but
> unlock specific pages that need to open for reading in general:
>
>     Site.EditForm
>     Site.SideBar
>     Site.Search
>     Site.PageActions
>     Site.PageListTemplates
>     Site.LocalTemplates
>     Site.EditQuickReference
>     Site.UploadQuickReference
>     Site.AllRecentChanges (?)
>     Site.Preferences
>
> The unlocking would be performed by having a special '@_system'
> read password on the above pages (similar to '@nopass').
>
> A _huge_ downside to this approach is that any recipes or skins
> that provide readable pages in the Site group would need to take care
> of unlocking those pages as well.
>
>
> Option 2:  Leave the Site.* group open as it is now, but lock
> certain pages that should generally be restricted to admins.
> This would include:
>
>     Site.InterMap
>     Site.AuthUser
>     Site.AuthList
>     Site.ApprovedUrls
>     Site.Blocklist
>     Site.NotifyList
>
> This approach has the (big) advantage of being less intrusive for existing
> sites and recipes, and there don't seem to be that many pages that need
> locking.
>
>
> Option 3:  Introduce a new SiteAdmin group that contains pages
> specifically intended for the site administrator.  This group could
> have a read password that limits viewing to the admin by default, and
> the pages listed in option 2 would move to this new group.
>
> The downside of this approach is that it complicates upgrading a bit
> in terms of moving existing Site.* pages to the new Site group, as
> well as introducing a new group to the distribution.
>
>
> At the moment I'm leaning heavily towards option 2.  Any comments
> or thoughts from others?
>

Independent of this particular decision I would in general not to let
transition considerations get too much in the way of structural decisions,
cf. option 1. Though there might be adaption necessary for particular
recipes, the needed changes can be clearly communicated in the pmwiki
Changelogs/Release notes and usually (as in this particular case) can be
expected not to make any trouble on specific sites. At the same time,
favouring the structural argument often exactly avoids transition problems
in the future.

Concerning this particular decision I'm still very neutral. All options
would lead to the most desired effect that the site admin does not have to
manually adjust read-attributes once a new admin page is added to Site.*
by the pmwiki engine.

Option 3, which employs the paradigm that permissions are implictly set by
organizing pages into respective groups, might still be the best idea _in
the long run_. It has a self-documenting effect (and thus improves keeping
overview over the system) -- the admin directly sees which pages are
protected. With "in the long run" I mean that I would not bother keeping
this for a major update.

Thomas







More information about the pmwiki-users mailing list