[ewiki] Re: PHP5.0.0b2, Re: ewiki_control_links()

        Good example.  Lets imagine an auth plugin written naïvely to delete
this kind of meta data from $data when the action is "info."  This same
plugin is accompanied by an administrative plugin in view_append that
processes this data into a form for access control.  Now, if the auth calls
in control links run on the same data that will be used by the later
view_append plugin then the ewiki_auth() function will have deleted the data
that the view_append plugin would expect to find there.  To prevent this
kind of unexpected effect I suggest that we either decide not to allow data
mangling in the ewiki_auth() plugins or not pass $data by reference to
ewiki_control_links().  Probably it would be better to leave the mangling to
a handler function since they are better positioned in the call scheme of
things.  What do you think?

-Andy


> The ewiki_auth() never alters the $data now on itself. However the
> ["auth_perm"]
> plugins still could do. There are in fact cases where this could be
> useful. One good
> example to comes to mind, was the "info/" page showing up most of $data.
> If
> now an ["auth_perm"] plugin keeps it's data in say the {meta} field (good
> idea)
> this would show up on the "info/" page for any given page.  This was ok,
> if the
> data in {meta} would be the name of the owner or group ownership of the
> page
> (UNIX-like page ownership like in CoWiki.org).
> If we however had an [auth_perm] plugin, that used a different restriction
> method,
> like placing an password into the {meta} field (to get queried before a
> page
> was edited -> "mv /my/idea /home/someoneelse/TODO"), then it was in fact
> bad
> if this password showed up with the "info/" action for that page. So here
> we had
> the case, where the [auth_perm] plugin would like to change $data
> (removing
> the password from {meta} immediately before "info/" prints it out).
> 
> Of course there were other hooks to strip confidential things out of
> $data, but it
> doesn't look wrong to let [auth_perm] plugins do that too (a single
> interface).
> Also it's clear, that now the [auth_] plugins must be written cleanly to
> not garbage
> the $data before other plugins get the chance to evaluate it - but that
> still sounds
> feasible.
> I even could imagine another (example/hypothetic) auth_ plugin that would
> keep
> it's ownership infos in a pages content, and strips it sometimes out from
> there like
> the notify: plugin does.
> 
> 
> mario
> 
> ________________________________________________________________
> Mit der Grupppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle
> Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179
> 
> 
> 
> 
> 
> _________________________________________________
> Scanned on 31 Oct 2003 23:42:24
> Scanning by http://erado.com

Other related posts: