[pmwiki-users] [pmwiki-devel] Rethinking ZAP permissions

[The Editor]

On 11/16/06, Rodney Morris <noctifer1011 at gmail.com> wrote:
> Rather than move away from AuthUser, I'd recommend bringing ZAP even
> more inline with AuthUser's options.  Since AuthUser has been bundled
> into the default install, there really won't be anyone who doesn't
> have the same options available, at least.

Yes, but many don't use membership based wiki's.  Some just use
passwords.  I'm not sure if ZAP works properly for those sites.  And
I'm not sure how much extra security adding the username gives to the
form submission.  Also, ZAP already relies fully on AuthUser for it's
authentication system.

> The question I mentioned on your site (which may or may not have
> spurred on this line of thinking) was whether ZAP could write directly
> to a text file for storing logins and encrypted passwords.  I'm trying
> to put my finger on exactly why, but the present method of storing
> login information on wiki pages seems to lack the security of storing
> it in a text file in a separate directory (particularly since the
> password stored by ZAP isn't encrypted).  I was very happy when I
> learned that AuthUser allowed alternative storage methods.

One option would be to have an encrypt option in ZAP.  But it might
makes things a bit more complex in some ways.  Right now it's very
easy for me as an admin to check passwords for people who forgot them,
or whatever.

I'm relying on PmWiki's ability to protect pages.  That is, you just
protect the page that has the data stored on it from viewing.  You
must also protect its source.

ZAP has a pretty powerful logging mechanism built into it.  It could
*perhaps* be made to store data to text pages outside the default
directory.  But then I'd also have to have a way to retrieve that data
back into PmWiki.  Now I can edit logs easily, etc.  All in PmWiki.

> Now, I'll be the first to admit I'm a fairly novice user and am just
> starting to learn how PHP and pmWiki works.  What I'm hoping for might
> not even be possible.
>
> To answer your questions more directly...
>
> I definitely support removing those security functions where ZAP
> overlaps with security functions available out of the box.  A single
> ZAPAdmin security id should be enough.  Or just hardcode it... require
> that people only be allowed to conduct the "plus" features when they
> use the admin password.

The problem is more that a novice admin might carelessly leave their
site unprotected in favor of ease of use.  The current setup requires
admins to take minimum security precautions.  Personally I like the
idea of using page attributes, and maybe the extra security is
overkill.  But then again, it's actually easier to use as is...  And
just as flexible.

> Having different forms available to specific users would be
> interesting, but even more powerful would be having different forms
> available to specific user groups.  The page I'm currently designing
> relies heavily on user groups (different people can access different
> parts of the site), so this is definitely an interest of mine.

Actually all this is already possible.  Just change the ZAP
permissions level to your group instead of id:* and submissions are
automatically limited to that group.

> Having ZAP automatically create a "lock pattern" would be wonderful.
> Or have a tutorial on your site with how to create your own, for
> novices like myself who are just now learning how to use pmWiki and
> php.

It's very easy to set up the lock pattern.  Just put something like this:

`Field1`Field2=value`Field3` inside your zapform markup with a space
before and after.  ie:  (:zapform `Field1`Field2=value`Field3` :)

Basically this causes any fields submitted beside Field 1,2 & 3 to be
ignored, and Field 2 will automatically be set to the given value.  No
other form submissions will be processed.

> Thanks for the work you've been putting into this, Caveman.  I'm
> really enjoying the possibilities ZAP makes available for pmWiki.

ZAP is pretty powerful.  I would love it if some of the more
experienced programmer at PmWiki could study it a bit more carefully
and make suggestions, but I keep plugging along doing the best I can.
I know I am planning to do some really things on my site.  Can't wait
to get past development to usage!

Cheers,
Caveman