permission matrix plugin

hi all,

i have picked up the fluxcms "permission matrix plugin" [1] and have  
been working on it for several days now. it took me some time to get  
to know the flux cms internals better first well enough to understand  
it ;) and then i didn't need to change much, for it's UI to do what  
seems good to me.

my intention in writing here is to inform on what exists and to see  
what the community thinks about. i also would like to point out one  
or two problems i encountered when testing the "permission matrix  
plugin" on the example of the blog plugin and find out if such  
problems will be exceptional rather than usual.

the philosophy behind the "permission matrix plugin" is to grant  
permissions for each plugin based on the array() that the plugin's  
getPermissionList() returns. in the case of the blog plugin, this  
would be [2]:

array(
     "blog-back-post",
     "blog-back-options",
     "blog-back-files",
     "blog-back-gallery",
     "blog-back-blogroll",
     "blog-back-categories",
     "blog-back-private",
     "admin_dbforms2-back-blogcomments"
     )

notice the syntax, consisting of dash-separated triplets [3]:

     [plugin] - [level] - [permission type]

permissions are set relatively to a collection path and can be  
inherited from a parent collection. say we have the following  
collection layout:

home
  |- blogs
  |   |- news          (blog plugin)
  |   |- internal news (blog plugin)
  |
  |- gallery           (gallery plugin)

then the /home permission UI would give you the possibility to edit  
blog and gallery permissions [4] for each user group (user groups are  
introduced by the permission matrix plugin). if not stated  
differently, all the child plugins shold inherit from these rights.  
it is now possible to overwrite the permissions for /blog/internal/  
and not grant any rights to the special "Anonymous" group.

basically, the permission itself is refereed by a triplet consisting of

     * collection path
       (e.g. '/blogs/internal_news/')
     * group id
       (e.g. Anonymous)
     * permission
       (eg. admin_dbforms2-back-blogcomments)

this also kind of reflects the permission management as i would like  
to see it. if you managed to read till here, i would love to hear  
what you think about this way of setting permissions.

at this point i would like to draw your attention to problems that  
can occur when using the "permission matrix plugin" on the example of  
the blog plugin. have a look at the first lines of the blog's  
handlePOST() function [5].

on line 50 the following function is called:

     $perm->isAllowed('/blog/',array('blog-back-'.$sub));
where
     $sub = "blog"

this interferes in two ways with the way the "permission matrix  
plugin" looks at the word:

the first problem is, that the "blog-back-blog" permission does not  
exist (c.f. [2], i guess "blog-back-post" could be the one we are  
looking for here). i guess such little problems will arise once in a  
while, but shouldn't be to difficult to fix.

the second problem might be more complicated to solve, and it might  
also be the reason why the "permission matrix plugin" paradigm isn't  
a good one. the collection path is hardcoded to '/blog/'. i haven't  
looked at the blog plugin internals, nor have i compared this with  
the behavior of other plugins... but the "permission matrix plugin"  
would expect a collection path here, in order to know which blog is  
referenced.

so here are the questions that burn on my tongue:
is a permission model, based on the path / user group / permission  
triplet realistic in the flux cms?
will there be many problems like the once i cited?
are there even issues i didn't consider yet?
what do you think about it?

best greetings ... pierre

**********************
Links and Annotations:
**********************
[1] http://wiki.flux-cms.org/display/FLX/Permission_Matrix

[2] http://fisheye.liip.ch/browse/PUB/fluxcms/trunk/inc/bx/plugins/ 
blog.php?r=9145&%40annotateMode=blame#l58

[3] problems can occur, should this nomenclature not be respected,  
like in the following example, where the permission is just "openid":  
http://fisheye.liip.ch/browse/PUB/fluxcms/trunk/inc/bx/plugins/admin/ 
overview.php?r=8612#l64
equally, for now, there is a hack on the "admin" and "edit" perms,  
resetting those with "permissions-back-admin", c.f.:
http://fisheye.liip.ch/browse/PUB/fluxcms/trunk/inc/bx/permm/perm/ 
matrix.php?r=7292#l79

[4] for sake of simplicity i will not talk about the xhtml and  
collection permissions present in every collection, nor of the  
permissions for the permission plugin itself

[5] http://fisheye.liip.ch/browse/PUB/fluxcms/trunk/inc/bx/editors/ 
blog.php?r=8447&%40annotateMode=blame#l45
--
Liip AG // Rte de la Fonderie 7 // CH-1700 Fribourg
Fon 026 4222511 // Key id 0x5BF5F8FA // www.liip.ch




-- 
bitflux-cms mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms