[ewiki] PHP5.0.0b2, Re: ewiki_control_links()
- From: "Mario Salzer" <mario@xxxxxxxxxxxxx>
- To: ewiki@xxxxxxxxxxxxx
- Date: Sat, 1 Nov 2003 00:42:18 +0100
Once more Hi @ all,
The current ewiki won't work with the recent PHP5 beta2 release, because of a
change
in the ewiki_array() function. The change was introduced there because of a
very silly
bug report and also resided into the CVS tree for PHP 4.3.x, where it recently
was
re-removed from. However the change still lives on for the PHP5 branch, and
eventually
the Zend guys will refuse to fix it back (they often enjoy the bugtrackers
"WON'T FIX"
state setting).
(<hidden_note> complaints may help </hidden_note>)
> Andy wrote:
> I suggest that either ewiki_auth() not alter data or that we not use
> pass-by-reference in this case, preferably the later. The problem is that
> an ewiki_auth plugin that would like to alter data for some page/action/user
> combination cannot tell that in this case the user will not actually be
> seeing this data and thus could destroy data that the other plugins will
> need for their operations. Any 'proper' data alteration would have been
> done by the ewiki_auth call in ewiki_page.
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
Other related posts:
