permission matrix plugin

[Spring Pierre]

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
bitflux-cms@...
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms

[Hannes Gassert-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pierre, hi all

Thanks for your great/big posting. I'm not qualified to give you any
definitive answers, but what I guess is the following:

> 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).

Yes. Just a trivial bug, methinks.

> 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.

I think the paradigm is a good one, I quite like the ACL-ish approach,
although I think what you refer to as "group id" should also be able
to contain just a user id.
Question here: what is the behavior for the cases where I'm in
different groups with possibly contradicting rules?

> 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.

Having multiple blogs inside one Flux CMS instance is a rather..
obscure/undocumented feature (setting a blogid and then ..), so if you
want to deal with the "which blog"  issue then you might want to look
into that. I'd say taking out the  hardcoded collection path is a good
idea.
Question here: what happens when I rename/move some collection? Do the
permissions reflect that change automatically?

> 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?

Yes. What else? The class Unix groups approach?

> will there be many problems like the once i cited?

There will be a bunch, but I suggest you first concentrate on making
the thing work with a coherent (beautiful?) UI for ordinary
collections and care about the special cases (files/gallery/blog ..
just guessing) afterwards?

> what do you think about it?

I think I'd love to see a cool UI for that thing! :-)

Keep up the good work, kind regards to Fribourg,
Hannes

- --
Liip AG // Agile Web Development // T [phone]
Schöneggstrasse 5  // CH 8004 Zürich // GPG 0x9EA04604

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHWEcczEcScZ6gRgQRAivXAKCALG+/8fzH7cK+GY4PGiQr/EnQqgCeIQi/
71VgJUhHmcSesHK9T16XPt4=
=ro27
-----END PGP SIGNATURE-----


--
bitflux-cms mailing list
bitflux-cms@...
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms

[Christian Stocker-7]

Hi

Just a little note before I (finally) leave :)

I basically agree with Hannes, I just wouldn't spent too much time on
the GUI part :)

As we will have some discussions next January where Flux should head to
(and where it should be improved) and one of those things is a more
coherent GUI, I wouldn't try to do fancy stuff there now. Later, no
problem :)

For the rest, I have nothing to add to hannes. And yes, it's better to
concentrate on the "normal" plugins like collection and xhtml/static
pages, than on the blog plugin and all those. They are the "pünktchen
auf dem i"

greetings

chregu

On 6.12.2007 20:01 Uhr, Hannes Gassert wrote:

> Hi Pierre, hi all
>
> Thanks for your great/big posting. I'm not qualified to give you any
> definitive answers, but what I guess is the following:
>
>> 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).
>
> Yes. Just a trivial bug, methinks.
>
>> 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.
>
> I think the paradigm is a good one, I quite like the ACL-ish approach,
> although I think what you refer to as "group id" should also be able
> to contain just a user id.
> Question here: what is the behavior for the cases where I'm in
> different groups with possibly contradicting rules?
>
>> 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.
>
> Having multiple blogs inside one Flux CMS instance is a rather..
> obscure/undocumented feature (setting a blogid and then ..), so if you
> want to deal with the "which blog"  issue then you might want to look
> into that. I'd say taking out the  hardcoded collection path is a good
> idea.
> Question here: what happens when I rename/move some collection? Do the
> permissions reflect that change automatically?
>
>> 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?
>
> Yes. What else? The class Unix groups approach?
>
>> will there be many problems like the once i cited?
>
> There will be a bunch, but I suggest you first concentrate on making
> the thing work with a coherent (beautiful?) UI for ordinary
> collections and care about the special cases (files/gallery/blog ..
> just guessing) afterwards?
>
>> what do you think about it?
>
> I think I'd love to see a cool UI for that thing! :-)
>
> Keep up the good work, kind regards to Fribourg,
> Hannes
>

--
Liip AG // Schoeneggstrasse 5 // CH-8004 Zurich
Tel [phone] // Mobile [phone]
www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB
--
bitflux-cms mailing list
bitflux-cms@...
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms

[Spring Pierre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

here a short response to your suggestions:


> I think the paradigm is a good one, I quite like the ACL-ish approach,
> although I think what you refer to as "group id" should also be able
> to contain just a user id.
> Question here: what is the behavior for the cases where I'm in
> different groups with possibly contradicting rules?
>

i think for now, permissions behave as the logical OR. if any group  
you belong to is granted privilege, you too are granted privilege.  
and this makes sense to me.


> [...]
> Question here: what happens when I rename/move some collection? Do the
> permissions reflect that change automatically?
>

this has been thought of. it is not implemented yet. but it shouldn't  
be too much of a problem.

greetings ... pierre

- --
Liip AG // Rte de la Fonderie 7 // CH-1700 Fribourg
Fon 026 4222511 // Key id 0x5BF5F8FA // www.liip.ch

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHXTp0fjG12Vv1+PoRAotTAJ0U/mwB8ahTPwRuuMnziFJXKpxCwACfdmKS
2fZHRH7K9XejMJn0Myek0iQ=
=lRKp
-----END PGP SIGNATURE-----
--
bitflux-cms mailing list
bitflux-cms@...
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms

[Spring Pierre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


hi all,

first i'd like to thank you for your answers. they quite helped me in  
finding a clear path for the next days ;)

but something keeps bothering me. it's best explaind with dbforms and  
permissions. when writing permissions concerning dbforms to the DB,  
the "permission matrix plugin" sets the collection path of the  
permission triplet [1] to /dbforms2/, as follows:

     // dbforms2 permissions are global
     // and not url bound
     if($plugin == 'admin_dbforms2') {
         $localUrl = '/dbforms2/';
     }

permission is the asked upon this path, e.g.

      $perm->isAllowed(
         '/dbforms2/',
         array('admin_dbforms2-back-users')
     )
      $perm->isAllowed(
         '/dbforms2/',
         array('admin_dbforms2-back-newsletter_from')
     )

the problem with that is obvious: you can not edit this permissions  
based on the collection path. but the UI will be based on the  
collection path...

if you take the blog example, you have admin_dbforms2-back-
blogcomments that is responsible to allow blog comments... if i want  
this permission to be different on two blogs, the permission plugin  
will only store the "last edited permission"... i.e. for both blogs,  
the identifying permission triplet is

     * /dbforms2/
     * group_id
     * admin_dbforms2-back-blogcomments

which is not unique.

i have no clue on how to attempt on solving this.

greetings ... pierre
==
[1] collection path / group id / permission
- - --
Liip AG // Rte de la Fonderie 7 // CH-1700 Fribourg
Fon 026 4222511 // Key id 0x5BF5F8FA // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHXTqlfjG12Vv1+PoRAtbLAJ4lNzwprFll2J4in9wYnCr6egV8vQCeNvWE
EZkrMbtWWKTfFOgvw8AQ8h4=
=/wIA
-----END PGP SIGNATURE-----
--
bitflux-cms mailing list
bitflux-cms@...
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms

[Hannes Gassert-2]

Spring Pierre wrote:
> first i'd like to thank you for your answers. they quite helped me in
> finding a clear path for the next days ;)

Great - can you tell us about your roadmap in a few words?

> when writing permissions concerning dbforms to the DB,
> the "permission matrix plugin" sets the collection path of the
> permission triplet [1] to /dbforms2/, as follows:
>
>      // dbforms2 permissions are global
>      // and not url bound
>      if($plugin == 'admin_dbforms2') {
>          $localUrl = '/dbforms2/';
>      }

Well, indeed database entities (or "Dbforms2") do live in a different
universe than the collections.Connecting them to the permission system
through a predefined collection URI makes sense to me. Problems might
arise later when you might want to try defining permissions for specific
forms/entities, but let's talk later about later, right? :)

> the problem with that is obvious: you can not edit this permissions
> based on the collection path. but the UI will be based on the
> collection path...

As said, I don't think this is a huge problem. If the collections have a
display-name you'll use that anyway, so if there's a thing called "DB
Forms" to which you can assign permissions all's fine, no?


> if you take the blog example, you have admin_dbforms2-back-
> blogcomments

I can't currently grasp the problem you're having.. is this a standard
case you name above?

> permissions behave as the logical OR.
> and this makes sense to me.

+1.

> > Question here: what happens when I rename/move some collection? Do the
> > permissions reflect that change automatically?
>
>
> this has been thought of. it is not implemented yet. but it shouldn't  
> be too much of a problem.

Great :)


Sending kind regards,
Hannes


--
Liip AG // Agile Web Development // T [phone]
Schöneggstrasse 5  // CH 8004 Zürich // GPG 0x9EA04604


--
bitflux-cms mailing list
bitflux-cms@...
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms