PmWiki | UserAuth2 / ExampleSetups

One-admin permission setups

See section "Simple usage" in Cookbook.UserAuth2.

Shared-administration setups

Example 1

Assume we want to set up a site with some editors alice and bob, which shall be able to create users and assign them spaces in the PmWiki for editing. Besides we want to have certain personalized private pages, say in group MyWiki, which only the user with the corresponding username can access.

Then the following setup might do. The records are in the form user_concerned: granter => permtable.

contentMask: (this is a user)
admin => xx_*.*,
         -xx_PmWiki.*,
         -xx_PmWikiDe.*,
         -xx_Site.*,
         -xx_MyWiki.*
         ad,
         cu,
         eu,
         ps

GuestUsers: (this is a group)
admin => rd_*.*, 
         -rd_Site.*,
         rd_Site.SideBar,
         rd_Site.MenuBar,
         rd_Site.PageActions,
         rd_Site.EditQuickReference,
         rd_Site.UploadQuickReference,
         rd_Site.PageListTemplates,
         rd_Site.PageNotFound

LoggedInUsers: (this is a group)
admin => xx_MyWiki.{$AuthId},
         pw

alice:
contentMask => ... (whatever you like alice to administer)
               ad,
               cu,
               eu,
               ps

bob:
contentMask => ... (whatever you like bob to administer)
               ad,
               cu,
               eu,
               ps

The trick is that, by deriving alice's and bob's permission record from the contentMask user, all their permissions (and thus what they can grant to new users) is restricted to that mask. Specifically, nobody of their children will be able to access MyWiki pages other than their own.

All logged in users may change their password (pw). alice and bob may access the admin tool (ad), create and edit users/groups (cu and eu), and set passwords for these users (ps).

Example 2

Permission granting for bigger entities in connection with wild cards. See http://article.gmane.org/gmane.comp.web.wiki.pmwiki.user/42957/.