On 5/26/07, <b class="gmail_sendername">Patrick R. Michaud</b> <<a href="mailto:pmichaud@pobox.com">pmichaud@pobox.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, May 26, 2007 at 02:06:05PM +0200, <a href="mailto:christian.ridderstrom@gmail.com">christian.ridderstrom@gmail.com</a> wrote:<br>> On Fri, 25 May 2007, Patrick R. Michaud wrote:<br>> >>Also, who has read access to these new passwd variables? Shouldn't
<br>> >>they be set to those with attr permissions, or are they...<br>> ><br>> >The default is to require attr permissions, but it's configurable. On<br>> ><a href="http://pmwiki.org">pmwiki.org
</a> I currently have it configured to require no permissions so<br>> >that people can see what it will look like from an admin perspective.<br>><br>> That makes sense. Just the name of a page can reveal information,
e.g.<br>> looking for a new house etc.<br><br>After getting some feedback I've decided to go ahead and make this<br>recipe part of the core... it seems very useful/important, and it's<br>relatively small.<br><br>
So, PmWiki will come distributed with a Site.AuthList page by default.<br>That leaves the question of whether viewing Site.AuthList should be<br>open or restricted to admins by default.<br><br>In fact, this brings up a larger question of what to do with the
<br>Site.* group in general... should we change the PmWiki default so that<br>viewing pages in the Site group is restricted to admins? There<br>are three options that I see:<br><br><br>Option 1: Lock the Site.* group to be read only by admins, but
<br>unlock specific pages that need to open for reading in general:<br><br> Site.EditForm<br> Site.SideBar<br> Site.Search<br> Site.PageActions<br> Site.PageListTemplates<br> Site.LocalTemplates<br> Site.EditQuickReference
<br> Site.UploadQuickReference<br> Site.AllRecentChanges (?)<br> Site.Preferences<br><br>The unlocking would be performed by having a special '@_system'<br>read password on the above pages (similar to '@nopass').
<br><br>A _huge_ downside to this approach is that any recipes or skins<br>that provide readable pages in the Site group would need to take care<br>of unlocking those pages as well.<br><br><br>Option 2: Leave the Site.* group open as it is now, but lock
<br>certain pages that should generally be restricted to admins.<br>This would include:<br><br> Site.InterMap<br> Site.AuthUser<br> Site.AuthList<br> Site.ApprovedUrls<br> Site.Blocklist<br> Site.NotifyList
<br><br>This approach has the (big) advantage of being less intrusive for existing<br>sites and recipes, and there don't seem to be that many pages that need<br>locking.<br><br><br>Option 3: Introduce a new SiteAdmin group that contains pages
<br>specifically intended for the site administrator. This group could<br>have a read password that limits viewing to the admin by default, and<br>the pages listed in option 2 would move to this new group.<br><br>The downside of this approach is that it complicates upgrading a bit
<br>in terms of moving existing Site.* pages to the new Site group, as<br>well as introducing a new group to the distribution.</blockquote><div><br>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.
<br></div><br></div>