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
contain:
--(:include GroupA.SomePage:)
--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?
From http://www.pmwiki.org/wiki/PmWiki/Passwords:
--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;
include_once("$FarmD/scripts/authuser.php");
--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.
Sandy
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
honoured.
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
place.
~Hans
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
