Just for clarification, my proposal did include a new way to write
permissions using groovy, but it also supports permissions as services
ad well as a new interface to implement very common permission
checking routines for re-usability.
This was only one part of the proposal, the main focus is on not
attaching the logic directly to the service instead it is attached to
a verbose permission. The reason for this is to make customization of
the permission logic easy to maintain, and not require modifying the
actual application.
The point is, the groovy part you keep referring to is just a minor
extra and not the focus of the framework.
Andrew
On May 3, 2009, at 1:38 PM, David E Jones
<david.jo...@hotwaxmedia.com> wrote:
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
--- 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.
Part of the point (if I remember right) of putting permission logic
into little services was to help keep it consistent when that
service is called in multiple places, especially in the input
processing service and the output generating screen.
If we have cases where a direct permission check is done on the
screen and a permission service is used for the input processing
service, then we should really change the screen to also call that
same service.
I guess the real trick with all of this is to make any easy way to
do dynamic permissions. So far we have these approaches on the table
(sorry if I missed any others...):
1. the current recommended practice of writing a service to perform
permission logic (service can be implemented in simple-method, java,
groovy, etc; normally the easiest way to write and maintain (and in
the future to create tools to help write and maintain) is a simple-
method XML snippet)
2. Andrew's new pattern of attaching a groovy script to certain
permission strings to override the normal behavior of that string
3. Adrian's idea to create some new expression (possibly extend what
Andrew has done) and add functions to the permission string itself
(which might eventually have boolean logic and other things, and be
a little expression language of its own)
Does that sound about right?
When comparing these the big question for me is what will be easiest
for users to maintain, especially less technical users (ie non-
programmers, or I guess also programmers with little time and
patience)?
In general I don't know if we'll EVER be able to come up with
something that allows non-technical users to easily configure
dynamic permissions to handle any possible situation. On the other
hand, maybe we can create something that handles most common cases
(including both functionality level and simple record level cases)
and leave in extension points so that it is possible to create more
complicated permission logic when needed.
In other words, however we do this we probably want some
configurable permissions that cover most stuff, and then extension
mechanisms to drop-down to lower level tools. That is the pattern
used in pretty much all of the OFBiz framework tools, and it would
be good to apply it here too.
A quick note on the extension mechanism: another pattern that has
emerged over time is to allow programmers to create custom logic and
put it somewhere that less-technical users can refer to. The reason
for this is that the custom stuff becomes a sort of tool that can be
documented and then used (but not manipulated) by less technical
users as part of their configuration. In other words the pattern
would look like the configuration part of things having the ability
to reference the custom logic part of things, and not the other way
around (to make it clear, that's a big distinction between #1 and #2
above, and I'm not sure about #3 since it seems to mostly be meant
to internalize things in the permission string/expression instead of
referring to external stuff, but could certainly easily point
explicitly to external stuff).
Anyway, THANK YOU Adrian, this message is a breath of fresh air
(part of why I changed the subject line :) ) and it's great to
discuss actual issues and patterns and possible solutions.
-David