[pmwiki-users] Privileges Cascade
Patrick R. Michaud
pmichaud at pobox.com
Sat Jan 21 20:12:46 CST 2006
On Fri, Jan 20, 2006 at 04:51:57PM -0700, H. Fox wrote:
> How can I accomplish the following in skin.php:
> Edit privileges give you read privileges.
> Upload privileges give you read and edit privileges.
Short answer: I think skin.php is very much the wrong
place to do this sort of customization -- it belongs
in config.php somewhere. As such, I don't (yet) know of
a good way to do it from skin.php.
However, getting a permission cascade ('edit' confers 'read')
to work is something I've wanted to add to PmWiki but needed
to wait for other authentication changes to settle out a bit
before committing to a particular solution. I think I have
one (feel free to skip to "Possible solution" below).
>From a design perspective, I don't believe that
operational/behavior changes such as this belong in a "skin" --
and I'd prefer that we limit the use of the word "skin" to
things that are primarily cosmetic (i.e., that directly
determine the display) and not start to include too many
functional/behavioral aspects in skin code.
This isn't to say that there's anything wrong with combining
output cosmetics with functional changes into a single package,
but at that point I think the package ceases to be a "skin" and
becomes something more substantial. As such, we should then
*call* it something other than a "skin" and treat it more like
we do other functional changes and less like a "skin"; i.e.,
it should be done with include_once('cookbook/...') instead
of $Skin = '...'; . I don't know if we need a special term
for packages that add functionality as well as a certain look,
but I don't think they should be lumped in with "skins". Or,
if they are, then perhaps they need to be given a special
Now then, I'm not saying all of this purely from a "this is how
I think things ought to work" perspective -- there are some
practical realities to the question that have to be recognized.
First, skins and skin.php are loaded somewhat late in the
customization sequence. This is a practical necessity -- because
the skin most directly affects what will eventually be displayed at
the end, it has to be able to react to whatever other configuration
changes might be taking place. This is especially true if there are
any per-page or per-group customizations taking place.
In contrast, I think that any customizations to the authorization
and authentication sequence need to take place very early in the
process, because other recipes and features in the system are
likely to depend on having accurate assessments of the identity
and privileges of the current visitor. Having the authorization
system change late in the game, as part of loading a skin,
feels wrong to me somehow.
This is also partially why the activation of authuser.php remains
an "include_once()" statement and not something like "$EnableAuthUser=1;" --
other customizations really need to be able to assume that the correct
authentication system is already in place.
So, back to the original question -- I can agree with the idea
that someone with edit privileges should also automatically get
read privileges. It's something I've been wanting to add to the
core, but I didn't want to just hard-code a "edit implies read"
rule, because it needs to be customizable and I'm still working out
the details for that. More on this in a bit. But as a direct
counter-example to the idea of hard-coding this particular logic,
I'm not so sure that upload privileges should automatically confer
edit privileges -- I can envision applications where uploading would
be allowed but not editing (e.g., students submitting homework
assignments through the wiki, or a file sharing repository).
What I am fairly certain of is that skin.php isn't the place
to be making changes to the authorization system. :-) I'm not
entirely sure of the motivation for wanting to place this into skin.php
(as opposed to a config.php item or other cookbook recipe), but at
first glance it seems to me to be something that ought to be orthogonal
to (and therefore available separately from) a "skin".
I've been thinking that a possible way to cascade permissions like this is
to simply allow $HandleAuth to contain arrays of authorization levels
as well as a single level. Thus, one could do:
$HandleAuth['browse'] = array('read', 'edit', 'upload');
$HandleAuth['edit'] = array('edit', 'upload');
which says that ?action=browse is available to anyone with
read, edit, or upload permissions, while ?action=edit is available
only with edit and upload permissions.
I haven't committed to this yet because we also have the
outstanding issue of dealing with the edit password on Site.SideBar,
where we want to have some setting to use the site default password
instead of the group-level one in Site.GroupAttributes. That's yet
another type of privilege cascade, and I'm thinking that the
"edit confers read" cascade and "Site.SideBar uses site default"
cascade might be two special cases of a more general solution
that I'm just not seeing yet (and I'd much rather build a single
general+flexible solution than multiple special-case ones).
More information about the pmwiki-users