A custom Privilege taking Method and Entity into account

Using Neos & Flow Flow App Development
1

While still working with the project metnioned in the thread about cached content I keep stumbling upon issues with a EntityPrivilege that is blocking for other methods.

Here is my usecase

A user visits the frontpage, and with a form enters a e-mail and hostname. That is taken into a user factory where the following is performed

$user = new User();
$user->setAccount($account);
$user->setEmailAddress($email);

if ($domain !== NULL) {
    $domain = Domain::create($domain);
    $user->addDomain($domain);
}

return $user;

As soon as I try to save this new user, the following EntityPrivilege kicks in

Neos\Flow\Security\Authorization\Privilege\Entity\Doctrine\EntityPrivilege':
  'Vendor.App:MyDomains':
    matcher: 'isType("Vendor\App\Domain\Model\Domain") && !(property("Persistence_Object_Identifier").in("context.userService.domainIdentifiers"))'

and I end up with a exception like Warning: PDO::quote() expects parameter 1 to be string, array given since I don’t have a any domainIdentifiers to give to the datbase layer (but that’s a different issue with the SqlFilter class).

Once a user is logged in, the EntityPrivilege is working as expected, only showing `my own domains filtered with the written matcher :ok_hand:

But, can I not make privileges that is based upon the combination of first a Method and then a Entity?

i’ve found that these interfaces (MethodPrivilegeInterface and EntityPrivilegeInterface) are used in the code to determine, when to do check. But if one fails, the whole requests fail, as I can seem to understand it?

Reading from the NodePrivilege classes from the Neos CMS package, there seems to be a concept of both method and entity privilege checking, hence the buildMethodPrivilegeMatcher method` and custom eel stuff taking over matchesSubject.

So dear mister and mistress of privileges and security…

How do I solve this? What is concept of the privileges and how should they be structured and organized to avoid me running into issues like the above?

Could this perhaps be the topic collection all sorts of hints, examples and good documentation, that I will then make into a commit to the documentation for that to be more explainable?

2

Hi Søren,

I’ll try to look into this, but I’m quite busy atm.
I didn’t read through the original thread yet, so could you quickly add one phrase describing what you’re trying to achieve?

Is it:
A user should be able to sign up specifying email address and a domain name but he should only be allowed to specify certain domains?

And what is userService.domainIdentifiers meant to return? I’d suggest to use a more explicit name here

1 Like
3

Hey,

it seems https://github.com/doctrine/doctrine2/issues/3955 is also a nasty issue we’re facing…

… Workaround from Aske: “here’s a workaround I used to prevent Doctrine caching the SqlFilter queries https://gist.github.com/aertmann/51ae0040b1ef179c208e#file-sqlfilter-php-L96-L97”

All the best,
Sebastian

1 Like
4

Thanks both @sebastian and @bwaidelich

I ended up having a fun day of detective work with the Neos related privileges and ended up getting quiet familiar with the Privilege, Context and Subject concept.

So, i ended up implementing my own Privilege classes with nice context classes, and now have a Policy.yaml like this

  'App\Vendor\Security\Authorization\Privilege\DeleteDomainPrivilege':
    'App.Vendor:MyDomains':
      matcher: '!(isInCollection("context.userService.domainIdentifiers"))'
```

**Important note:**
This is totally decoupled from the entity privilege concept and is all done in code and not on database level. So no issues with the SqlFilter bug that have been referred to :-)