Don't need to actually respond to any particular thing David said,
just reusing his change of subject for my email.
==
PermissionNameOrPattern Command Action Roles
----------------------- ------- ------ -----
/Path/To/Resource UPDATE ALLOW \
(FOO_ADMIN|FOO_UPDATE)&FOO_TRAINED
/Path/Pattern.* CREATE ALLOW \
(FOO_ADMIN|FOO_CREATE)&FOO_TRAINED
PARTY_MGR READ ALLOW \
PARTY_ADMIN&PARTY_TRAINED
==
We have something similiar to this in our client apps. It hasn't yet
made it to the base webslinger code. It's not any kind of fancy
parser. Just tab separated(for now, that would have to change if the
Name allowed spaces).
The 'framework' is the parser, and the api that can be called by
code($resource.userAllowed($user, $command)). The
Command/Action/Roles are not hard-coded.
Again, I haven't actually read the proposal. The above makes the
application code easy to understand. It's not polluted with
boiler-plate security code; instead, it has a simple string that can
be descriptive of what it is checking. It allows clients to change
the security(based on whatever policy they have), without having to
understand any kind of programming logic.
I'm fairly good with javacc. The above would be *simple* to write a
javacc parser for. I've got a SQL parser sitting in the wings, as is
what I was actually working on this weekend, trying to add it to ofbiz.
