Confusing ACE definitions using registered callables

[vlcinsky]

Real example of ACL from raml-example

ramle-example repository provides an example.raml

            item: |
                allow g:admin all
                allow everyone view,options
                allow {{user_self}} update

One would expect the last line to allow some callable to dynamically calculate a principal which will be allowed to update the item.

ramses_example/init.py really provides a function user_self:

@registry.add
def user_self(ace, request, obj):
    """ Give 'update' permission to user that is being created. """
    from pyramid.security import Allow
return [(Allow, str(obj.username), 'update')]

Suprise: words around callable are ignored

What surprised me is the fact, the callable does not provide only name of currently authenticated user, but also defines set of ACEs for him.

Reading ramses code ramses/acl.py I came to conclusion, that the callable really replaces the original line from RAML file and is able to put in it's place one or more ACE "lines" dynamically calculated by the callable.

To me it seems a bit confusing, that there is an instruction in RAML file consisting from three parts and two of them ("allow" and "update") are silently ignored.

Proposed solution

Thinking of possible solution, I would propose to require all ACEs containing a callable to use following syntax:

dynamic {{callable}} dynamic

(of course, if you come with better word than dynamic I would not complain).

Current code works

Current code (ignoring action and permission part of the ACE) does not prevent one to use it for developing functional application. It is enough to realize, that any ACE line containing a callable simply ignores the action and permission word around it.

Anyway, implementing more intuitive way of expressing dynamic parts of ACLs would be welcome.