[pmwiki-users] security documentation for recipes
Peter & Melodye Bowers
pbowers at pobox.com
Fri Mar 7 08:28:29 CST 2008
> > Would it be helpful for other developers (or is it just me?) to have a
> > simple wrapper as the "official" way to write to a page? Something like
> > UpdateAuthPage() or something similar?
> Possibly, but there are a couple of issues that need to be resolved
> first. For example, presumably a call to UpdateAuthPage() would
> look like
> UpdateAuthPage($pagename, $page);
I would have thought
UpdateAuthPage($pagename, $auth, $oldpage, $newpage);
That would maintain a little more consistency with both UpdatePage() and
RetrieveAuthPage() as well as giving some more flexibility. Then if
$oldpage was non-array then the page would be read via RetrieveAuthPage()
and passed on to UpdatePage()... The $auth is probably unnecessary - is
there any time you would want to require auth other than "write"? Maybe
there would be a time when you knew you wanted 'admin' privileges before
writing a certain page even if you had 'write' privileges? Not sure on that
one... Basically I'm not thinking UpdateAuthPage() would be used any
different from UpdatePage() (i.e., still has the $oldpage parameter) other
than making sure that authorizations were correctly respected - an
"authorized API", if you will, to the world outside core...
> where $pagename is name of the page to be updated, and $page is the
> array of new attributes. One question is whether the $page array
> should _completely_ replace the existing array (as currently happens
> for UpdatePage), or if it simply supplies the attributes to be
> updated and leaves the remainder unchanged.
Interesting question, but perhaps a decision that can be made independently
of the UpdateAuthPage() if I'm understanding correctly? It seems like
whatever UpdatePage() does should be exactly replicated in
UpdateAuthPage...? Just a wrapper function that makes sure I didn't allow
someone to do something they aren't supposed to...
> Also, what should UpdateAuthPage() do if the visitor doesn't
> have authorization -- should it automatically prompt for a form,
> Abort, return a false value to the caller, or... ? (We could provide
> a $prompt argument to UpdateAuthPage() as well.)
Here I go off on what may be a total rabbit trail... Is there any reason
why authorization is done on a page by itself rather than using some kind of
popup dialog box? I ask that question in all naivete - I know that if I go
into a secure site or something there is often a dialog box that pops up to
ask for my username and password so I'm assuming there's some kind of
browser function or something for it. If that happened as the main
authorization method in pmwiki it seems like it would allow a much more
direct approach rather than having to worry about redirects and where we're
headed and etc. I'm thinking of something like this:
if (!CondAuth($pagename, $auth) and !AskAuth($pagename, $auth))
There's probably some very good reason why this can't be done, but I've been
curious about it for some time so I tho't I'd throw it out there...
> > On another note, does CondAuth() work as well (in place of the
> > RetrieveAuthPage() call)? Sometimes I read a page ("read" auth) and
> then in
> > the process of working with it realize I need to update the page -- it
> > a shame to re-read it to confirm "edit" auth...
> In general if you simply want to check authorization and don't care
> about the page contents, it's better to use CondAuth() instead of
> RetrieveAuthPage(), just in case we modify the security model in the
> future. However, it's not any quicker, since CondAuth() itself uses
> RetrieveAuthPage() to check the permissions.
Curious. I guess there's some technical reason why CondAuth() calls
RetrieveAuthPage() rather than checking $page['=auth']['edit'] (as below) or
something similar...? It seems from a performance perspective like a check
of permissions shouldn't require a full read of the file, but I've never
gotten that deep into the code to see how it happens so I may be completely
off base here...
> Another way of checking that doesn't require an extra read beyond
> the first is to check $page['=auth']['edit'], if non-zero, then
> the visitor has 'edit' permission on the page.
Is this a "safe" bet for the future if the security model changes? Or
better to use CondAuth()? I'm guessing the latter?
More information about the pmwiki-users