[Neos] Make your own privilege: Why is MethodPrivilegeInterface hard-coded in class PolicyEnforcement

[Bastian Waidelich]

On 21.04.15, at 10:38, Olle Haerstedt wrote:

Hi again,

> So, what is best then - to implement MethodPrivilegeInterface or extend
> the already present class?

as usual, it depends ;)

As you have figured out already, matchers of standard *MethodPrivilege*s 
are written using *PointcutExpressions*[1].

Matchers of the default *EntityPrivilege* are written using *Eel* syntax[2].

More interesting for your case, are the custom *node*-related privileges 
we've built *on top* of those default privileges:

Take for example the *EditNodePrivilege*[3] - it uses the "Decorator 
Pattern"[4] to wrap a *MethodPrivilege* but it consumes Eel..

Sounds rather complex and it is in a way, but it will be pretty easy to 
implement once we finished our little tutorial.


> Maybe there should be an exception too, when a privilege target in
> policy.yaml doesn't implement
> either of those two interfaces (method or entity).

You get an exception if your privilege does not implement 
*PrivilegeInterface*, the rest is up to you. Usually you want to 
implement the *MethodPrivilegeInterface* (in order to activate 
PolicyEnforcement) but you could also have a completely independent 
privilege that you only check using the *PrivilegeManager*.


HTH


[1] 
http://docs.typo3.org/flow/TYPO3FlowDocumentation/latest/TheDefinitiveGuide/PartIII/AspectOrientedProgramming.html#pointcuts
[2] 
http://docs.typo3.org/neos/TYPO3NeosDocumentation/latest/IntegratorGuide/EelFlowQuery.html
[3] 
https://git.typo3.org/Packages/TYPO3.TYPO3CR.git/blob/HEAD:/Classes/TYPO3/TYPO3CR/Security/Authorization/Privilege/Node/EditNodePrivilege.php
[4] http://en.wikipedia.org/wiki/Decorator_pattern


-- 
Bastian Waidelich