--- On Sat, 5/2/09, David E Jones <david.jo...@hotwaxmedia.com> wrote:
> My personal opinion on this is that the design has only
> subjective improvements and most of it is a big step
> backwards (easier but less flexible, for the services versus
> direct permission part anyway, and we decided long ago that
> flexibility was better than ease in this case; and yes there
> is a creative way to invoke code attached to permissions,
> but that is a bit inflexible IMO since much permission logic
> involved multiple permissions... it's the artifact we
> want the code attached to not the permission itself)
I've been thinking about that aspect of it. If I understand correctly, here are
two of the issues being addressed by the new security:
1. Permission checking is being done in scripts, so a programmer is required to
change the permission checking logic. An ordinary systems administrator with no
knowledge of mini-language would not be able to change how permissions are
checked. The new permission string is supposed to make changes to permission
checking easier for the non-programmer administrators.
2. Permission checking isn't consistent. Two similar branches of logic will
check permissions in two different ways: one will check a permission string,
and another will run a script. This is common in the UI versus the services
called by the UI. A simple "has permission" check is done in the UI, and then
the service invoked runs a script to check permissions.
I agree with you that substituting the permission service with a permission
string is too inflexible.
One of the ideas I've been toying with is the idea of a permission expression.
I started writing some code for that and was going to put it in Jira, but I
decided to put it on the shelf until the dust settles from this thread.
Let's say we took Andrew's new permission string and gave it more oomph - where
it could contain functions and such. (The expression language would be simple
enough for common administrators to understand.) That could eliminate many of
the permission checking scripts. In effect, the permission string becomes a
mini-script. This mini-script could be used anywhere a permission string is
being used now.
One of the problems I have with what has been proposed so far is that the
permission string can be ambiguous when it comes to inserting parameters. For
example, "update:example:${exampleId}" - what does that mean? There's no way to
tell by looking at it. It would be preferable to have something like
"update:example + relatedTo(exampleId)". That permission tells me something -
it requires update:example permission and the user must be related to exampleId
in some way.
I think permission expressions would solve both of the issues above.
-Adrian
