[pmwiki-users] Passwords for Groups, Pages and Actions

[Petko Yotov]

On 02/04/2023 13:44, kirpi at kirpi.it wrote:
> I am not sure that I understand how pmwiki passwords work, although I
> have been using them since many years now.
> My website is completely closed for writing and partially open for
> reading.
> In config.php I have:
> 
> $DefaultPasswords['admin'] = pmcrypt('adminpassword');
> $DefaultPasswords['edit'] = pmcrypt('normalgeneralpassword');
> $HandleAuth['browse'] = $HandleAuth['upload'] = $HandleAuth['attr'] =
> $HandleAuth['print'] = $HandleAuth['refcount'] = $HandleAuth['diff'] =
> $HandleAuth['source'] = $HandleAuth['search'] = 'edit';
> 
> This way (I guess) all pages are fully protected both for writing and
> reading.

For most of these, and reading your full message, it may be simpler to 
set $DefaultPasswords['read']:

   $DefaultPasswords['read'] = pmcrypt('normalgeneralpassword');

Also that is 'read' not 'browse'.

With $DefaultPasswords, 'read' it applies to most actions including 
'browse'. If you use 'browse' it only applies to the 'browse' action, 
not to 'diff', 'print', etc.

There is no $HandleAuth['read'] as there is no such action (in the 
core).

Now, you want to restrict 'diff' and 'source' to editors, you did it 
correctly:

   $HandleAuth['diff'] = $HandleAuth['source'] = 'edit';

> Also, I can choose which actions are closed (all the above are closed
> for writing and reading) while, as an example, I keep open
> presentations (action=slideshow, see S5 recipe).
> But this would open a hole so I should most probably update to
> 
> $HandleAuth['browse'] = $HandleAuth['upload'] = $HandleAuth['attr'] =
> $HandleAuth['print'] = $HandleAuth['refcount'] = $HandleAuth['diff'] =
> $HandleAuth['source'] = $HandleAuth['search'] =
> $HandleAuth['slideshow'] = 'edit';
> 
> Is this approach safe enough? Do you see anything that would raise a
> warning, please?

For the PmWiki core actions, such configuration could work.

For custom actions by recipes, or for core actions that have been 
overtaken by recipes, it depends how the recipe is designed - 
$HandleAuth['custom-action'] may or may not work.

With Cookbook:Slideshow it should work.

> As other actions might exist which might pose a threat, is there a way
> to tell the system: "block all actions except xyz", instead?

I suppose you could do something like this in config.php:

if(!preg_match('/^(browse|edit|search|slideshow)$/', $action)) {
   $action = $_GET['action'] = $_POST['action']
    = $_REQUEST['action'] = 'browse';
}

See PmWiki:AvailableActions for some of the available actions.

Although, if some scripts on your hosting plan pose threats, you have 
bigger problems. Just restricting which action PmWiki allows wouldn't 
stop a rogue script from doing damage.


> Moreover, when I try to free reading for a whole group with
> www.example.com/GroupName.GroupAttributes?action=attr [1] and place
> @nopass in the 'read' field, it does not work and the group is kept
> closed.
> 
> What am I doing wrong, please?

When $HandleAuth['browse'] = 'edit'; there is no 'read' password, the 
field is ignored. PmWiki would use the password or @group/@nopass from 
the 'edit' field. But I suspect you don't want to set that field to 
@nopass.

Similarly with $HandleAuth['search'] = 'edit'; unless the user is also 
editor, they cannot search.

What should work for the 3 above is setting a $DefaultPasswords['read'] 
in config.php for all groups, and unrestrict GroupName with @nopass like 
you did.

Petko