@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.
Real example of ACL from raml-example
ramle-example repository provides an example.raml
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
: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:
(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.