[pmwiki-devel] Rethinking ZAP permissions
Jiri Hladůvka / OBUTEX
admin at obutex.com
Thu Nov 16 08:34:18 CST 2006
The Editor napsal(a):
> 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
Would you explain what "to zap" means ?
> ... (ZAP has never been
> hacked to my knowledge).
Isn't it too soon to make such a conclusion? The ZAP modules are not in
the center of hackers interest yet.
But on some sunny day someone will try to missuse them. I will be carefull.
BTW I use the AuthUser features to test if to display Submit buttons or not.
I thought that if the submit button is not displayed then the form stays
Should I test the (:input hidden savedata ... as well ?
> 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
I think that form creation should be on admins shoulders. He/she will be
who can submit the forms. Then it is logical to list groups or pages (or
even pagename templates) where the ZAPform
can be executed (page headers, footers, templates). Thus the visitors
still can be allowed
to create and edit pages but if they edit some page (out of the range of
and insert there a ZAPform then the form refuses the processing.
> Second, I'm thinking about removing the AuthId from the security
> session variable so ZAP works better with password based sites (not
> using AuthUser).
I don't know what the "security session variable" is.
I think the admin should have the site under control himself using the
pmwiki core features
not to think about a lot of security variants.
911 01 Trenčín
tel.: +421 (0)32 6587000
mailto:admin at obutex.com
More information about the pmwiki-devel