[pmwiki-users] Setting DefaultsPasswords via config files

[Patrick R. Michaud]

On Fri, Jun 08, 2007 at 11:45:51AM +0200, Christian Bartolomaeus wrote:
> Hi,
> 
> reading some recent posts about read protection I remembered a problem
> I encountered a while ago.
> 
> Let's say I have a group "GroupA" which I want to be read protected
> with password "foo". That password is given to all readers of GroupA.
> Since I can't remember all those passwords I use a configuration file
> local/GroupA.php with:
> 
>   $DefaultPasswords['read'] = crypt('foo');

This won't work ... read passwords cannot be set in per-group
customization files.

The reason it won't work is that per-group 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.

The only way to set read passwords on pages is by using ?action=attr .
I thought this was already mentioned in PmWiki.PasswordsAdmin, but
I can't see it there now (and it looks like someone has added some
incorrect information to that page, which I need to correct).

> I expected PmWiki to read the values from local/GroupA.PageA.php and
> override the value from local/GroupA.php. What is the reason that it
> does not?

Assuming that $DefaultPasswords['read'] would work, the problem
is that per-page customizations are loaded _before_ group
customizations.  So, the setting in local/GroupA.php is overriding
the setting from local/GroupA.PageA.php .

While this might seem backwards to what you expect, it's in fact
correct.  Many times what we want to do is to enable a certain
capability for a group of pages, but disable it on a specific page,
as if it was never enabled.  If the per-group config file is processed
first, then it becomes very difficult/tedious for the per-page one
to "undo" the effects of the per-group page.

So, we load the per-page file before the per-group.  If a per-page
customization wants the per-group customizations to be performed first,
it can start with:

    include_once('local/GroupA.php');
    ## now do any per-page overrides here
    ## ....

It's also possible for a per-page customization to say "don't load
the group or other customizations" by setting $EnablePGCust = 0; .

Hope this helps,

Pm