[pmwiki-users] ZAPauth & PmWiki

[The Editor]

Thanks very much for the info.  Very helpful. The more I see how
PmWiki was designed the more I want ZAP to tap into its existing
features as closely as possible, as PmWiki is truly a brilliant piece
of software.

On 10/16/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Mon, Oct 16, 2006 at 04:49:47PM -0400, The Editor wrote:

>     SDV($ZAPauth['email'], 'admin');
>     if (CondAuth($pagename, $ZAPAuth['email'])) execute emailer();

This is clear enough.  I presume it will automatically get the user's
info from the cookie.  So I don't need to submit it in any way with
the form, correct?  This will help at least by allowing me to restrict
certain features based on user permissions. But for non-authenticated
users, it won't do much of anything, or is there some session value
set immediately upon browsing a PmWiki page that can differentiate a
page visitor from a forged header? Maybe based on an ip address or
something?  IE, something connected with a "read" auth?

> > > > > Also, on a related note, how does PmWiki avoid forged headers with an
> > > > > upload form?  ...
>
> PmWiki doesn't care if the form comes from a PmWiki page or from
> some other source (e.g. forged) -- that's not the basis for PmWiki's
> security.
>
> Using the upload example -- when someone (or something) makes a submission
> to PmWiki to upload a file, the submitted form contains the upname,
> upfile, etc.  fields as you describe above.  At that point PmWiki
> asks the question "Is the submitter authorized to upload the file I've
> just received to the page specified by the form?"  It does this by
> making a call to RetrieveAuthPage, as in:
>
>     $page = RetrieveAuthPage($pagename, 'upload', true, READPAGE_CURRENT);
>
> RetrieveAuthPage looks at any authid/authpw fields in the form
> just submitted, as well as any credentials previously entered for
> the session (stored in session variables) to determine if the
> action is allowed.  The 'true' argument in RetrieveAuthPage
> says that if the action is not allowed, then send back an
> authorization form to obtain the credentials needed to
> perform the operation.

This is very nice.  I presume if you left out the "true" or set to
"false", the action would just fail? "upload" can be any action?  And
what is $page, a boolean?  Or does this line actually initiate the
action if it passes muster?

> You may reasonably ask why I suggested the "keep track of
> which forms have been sent out" approach in an earlier mail
> on this topic.  The answer is that ZAP seems to want a
> different approach to access control -- ZAP wants to allow
> people to create and modify pages even if they don't have
> edit permission in the PmWiki sense, and ZAP wants the
> displayed input form to determine which page(s) the end-user
> is allowed to modify on a subsequent request.  That's a
> substantially different model (and has more room for unwanted
> surprises) than the "every-request-carries-its-own-credentials
> or is prompted for them" model that PmWiki implements.

Yes, it is true, ZAP bypasses normal permissions, but I may need to
create new permissions based on the ZAP action, and just use that
instead of edit or read.  Then I should be able to use the PmWiki
system more closely.  ZAP would just mean permission to submit and
process a form.  I remember you gave me some information about how to
set ZAP as a page attribute--now I understand more fully what that
means.

> Still, this is a problem quite similar to the one I'm
> having with ?action=insert, so it's possible that the core
> will add "authorize based on having seen a given form in
> the current session" abilities too.  But the authorization
> code is already such that I'm wary to make too many changes to it,
> and I'm not keen on adding *yet another* dimension to the
> core authorization code, since it has so many already.

How would action=insert be different?  Already PmWiki allows open
editing unless you choose to clamp it down.  This seems to be another
way of allowing that.  What it can do is very limited--just insert
text to a page.

The problem with ZAP of course is it has more dangerous
capabilities--with power to do all kinds of damage!  : )  For most
uses I can require a user to be logged in which should prevent forged
headers, but there's no way to do that for a login form!

I think the random number idea has great merit, BUT it seems it must
be tagged to something connected to the user to really work.  Maybe an
IP address.  Or perhaps, if I set the session variable to the
pagename, and the value equal to the random number, that would work.
The hacker knows the pagename, but can't create the variable. The
question remains though, can a forged form be created that looks like
it is coming from a given pagename, and fool PmWiki into believing it
is from Main.SomeForm? Otherwise the could browse to the form page,
steal the random number and pass it in that way...  : (

I've been thinking about adding a locking option which allows you to
define which fields can be processed and storing that as a session
variable when the form is marked up.  This would ignore anything else
submitted. Or perhaps defining a field list in a config file for zap
forms submitted by unauthenticated users.  This would unfortunately,
probably prevent the auto login feature, which several people have
asked for.  But maybe not... Hmmm.  Ideas...

Thanks again for helping me work through this.  I know ZAP will be a
useful addition to PmWiki once it is on a secure foundation, and the
code snippets begin to proliferate.  I have recently come up with some
clever forms to emulate intrasite email between members, using
pagelists.  It is quite powerful.  Even better than the instant
messaging system I use now, which is based on comment boxes.  Ahhh,
but to get past the secure foundation...

Cheers,
Caveman