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

[Tegan Dowling]

On 5/26/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>
> On Sat, May 26, 2007 at 02:06:05PM +0200, christian.ridderstrom at gmail.comwrote:
> > On Fri, 25 May 2007, Patrick R. Michaud wrote:
> > >>Also, who has read access to these new passwd variables? Shouldn't
> > >>they be set to those with attr permissions, or are they...
> > >
> > >The default is to require attr permissions, but it's configurable. On
> > >pmwiki.org I currently have it configured to require no permissions so
> > >that people can see what it will look like from an admin perspective.
> >
> > That makes sense. Just the name of a page can reveal information, e.g.
> > looking for a new house etc.
>
> After getting some feedback I've decided to go ahead and make this
> recipe part of the core... it seems very useful/important, and it's
> relatively small.
>
> So, PmWiki will come distributed with a Site.AuthList page by default.
> That leaves the question of whether viewing Site.AuthList should be
> open or restricted to admins by default.
>
> 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.


I'd favor option #3, as it formalizes something I already try to do - I
already have an Admin wikigroup in my template site that is read-enabled
only for admins.  Option three, here, would move into it stuff that I would
already have moved if I could.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20070526/e0927395/attachment.html