sandy at onebit.ca
Tue May 3 14:49:52 CDT 2011
Aha! I get it.
Here's the bit about using group config files to set passwords. Turns
out it shouldn't be done:
From http://www.pmwiki.org/wiki/PmWiki/PasswordsAdmin :
--As described in PmWiki.GroupCustomizations per-group or per-page
configuration files should _not_ be used for defining passwords. The
reason is that per-group (or per-page) customization files are only
loaded for the current page. So, if $DefaultPasswords['read'] is set in
local/GroupA.php, then someone could use a page in another group to view
the contents of pages in GroupA. For example, Main.WikiSandbox could
--and because the GroupA.php file wasn't loaded (we're looking at
Main.WikiSandbox --> local/Main.php), there's no read password set.
Here's something that looks vaguely like Peter's method. Is it still
valid, or should the docs be changed?
--How can I create private groups for users, so that each user can edit
pages in their group, but no one else (other than the admin) can?
--Administrators can use the AuthUser recipe and add the following few
lines to their local/config.php file to set this up:
$group = FmtPageName('$Group', $pagename);
$DefaultPasswords['edit'] = 'id:'.$group;
--This automatically gives edit rights to a group to every user who has
Overall, much as I appreciate the ability to poke around in the program,
I'm going to avoid doing so. There's too much interconnection, and no need.
On 5/3/2011 2:46 PM, Hans wrote:
> Tuesday, May 3, 2011, 6:35:11 PM, Sandy wrote:
>> If it is possible to see and (:include:) file which you don't have
>> access to, and access was set properly, then it's a bug.
> Peter's point was that page specific authorisations always need to be
> set in the page, via action=attr, or in the groups GroupAttributes
> page, via action=attr, never via conditionals in config.php.
> All $DefaultPasswords items should be set in config.php only, and not
> set with group or page specific conditionals, as these will not have
> any effect for a page which is included via (:include ...:).
> But an included page's (access-) attributes will be recognised and
> So there is no bug. One just cannot do a shortcut of setting page or
> group specific access authorisations in config.php or a Page or Group
> php file. They need to be set in the page.
> The spread of authorisation settings on multiple pages is unavoidable
> in PmWiki's security model. AuthList just helps to see it in one
More information about the pmwiki-users