[pmwiki-devel] Rethinking ZAP permissions

[The Editor]

Someone just asked me a question about ZAP security that got me
thinking of what may be a better system.  Thought I would post it to
the list and see if anyone has any input.

Currently zap divides it's functions by risk level into the following
categories:

SDV($ZAPauth[login], "read");
SDV($ZAPauth[forms], "zap");
SDV($ZAPauth[plus], "admin");

"zap" is a custom permissions level that shows up in the page
attributes page by default as id:*.  This allows you to have pages
people can read and not zap or edit, or pages people can read and zap
but not edit.  Probably what Pm will do for the upcoming commenting
feature.

Anyway, the thought occurred I could just require all zap features to
use the zap permissions level, and then leave it with the web admin to
set the desired level of protection for each form using page (or
group) attributes.  It would be a bit more trouble perhaps, but more
intuitive, and allow them more flexibility and control--without the
need to modify config files.  It would also simplify the coding some.
And it is more in line with how PmWiki works already.

The disadvantage is that any form without a lock pattern could
potentially be hacked (forged headers) giving that person access to
all ZAP's commands (modules) avaiable on that page.  Admin's might be
tempted to think that because a form only has simple features it
should be available to any viewer, or any member--not realizing all of
zap is potentially available to a skilled hacker.  (ZAP has never been
hacked to my knowledge).  ZAP "lock patterns", of course, would
continue to be available.  And the risk is somewhat mitigated by ZAP's
new modular structure, which can enable riskier modules only in
certain groups... But one of my design goals was to avoid having to
edit multiple local config files wherever possible.  Maybe a
ZAPallow[module] variable with a CSV list of groups/pages where that
module can be checked?  That way everything could be set in one config
file...

Second, I'm thinking about removing the AuthId from the security
session variable so ZAP works better with password based sites (not
using AuthUser).  Doing both of these together adds some nice
possibilities, like having different forms available to specific
users, or those with specific passwords, or whatever.  Anyone have any
thoughts?

How about an even wilder idea:  what if ZAP could automatically create
a "lock pattern" for each form?  Is there some way the (:zapform:)
markup can access the text of the page it is on, retrieve all the
input fields, parse the args and proceed from there?  Perhaps you
could prepend a field value with some symbol ( ` ) to indicate that
value is not changeable, and then strip it out in processing.  Any
thoughts?

Cheers,
Caveman