Question about the multisite feature of Neos: is it possible to assign each user to different sites, regarding if the user can edit a site or not ?
In the user management module, I did’t saw any options. Is it feasible via the configuration in the YAML files ? When yes, any example ?
Hey
Unfortunately it’s pretty difficult to achieve with the current ACL implementation to be honest, due to missing things and a couple of bugs.
Personally used a custom SQLFilter policy to do it myself, because it had to be dynamic. If you can accept the restrictions being hardcoded (site paths and roles), then you can more easily achieve it. However due to https://jira.neos.io/browse/NEOS-1371 it’s impossible only to apply restrictions when logged in, or at least I didn’t find a way.
It would make sense to add an issue to https://jira.neos.io/browse/NEOS-177
Maybe @bwaidelich or @andi know more.
Yes, that should be fairly easy using the NodeTreePrivilege. For the moment this means that you need at least one Role per site though (we’re working on a “groups”-feature that allows you to add parameters to a role, so this won’t be needed in the future).
Given you have two sites “site1” and “site2” the Policy.yaml could look like:
privilegeTargets:
'TYPO3\Neos\Security\Authorization\Privilege\NodeTreePrivilege':
'Your.Site1:EditPrivilege':
matcher: 'isDescendantNodeOf("/sites/site1")'
'Your.Site2:EditPrivilege':
matcher: 'isDescendantNodeOf("/sites/site2")'
roles:
'Your.Site1:Editor':
privileges:
-
privilegeTarget: 'Your.Site1:EditPrivilege'
permission: GRANT
'Your.Site2:Editor':
privileges:
-
privilegeTarget: 'Your.Site2:EditPrivilege'
permission: GRANT
Now users with the role Your.Site1:Editor should have write access to all nodes of site1 and Your.Site2:Editor-users to nodes of site2 (untested).
Roles and privileges are an application-wide concept so they should be prepared by the developer/integrator via Policy.yaml. There are some concepts for a “Policy.yaml builder” (see RFC: Policy.yaml backend module for example) but usually this is something you don’t want to change during production!
However, with the “groups-feature” mentioned above it will be possible to specify certain parameters in the user module like user <foo> has role <editor> for site <site1> (see https://jira.neos.io/browse/FLOW-386 if you’re interested about details).
OK, thanks, it’s very clean and clear so
Thanks for sharing. One problem with this solution is that it still allows you to go into any site, which is confusing.
Ah: that means that everybody can see any “subsite”, but edit it regarding the policies ?
With the NodeTreePrivilege changing protected nodes is intercepted at the server-side. In addition those nodes won’t appear in the navigate component.
If you navigate to a (document) node you don’t have access to the inspector won’t show any editors
Then I don’t fully understand the remark of @aertmann: "it still allows you to go into any site"
Via the URL then ?
@tbrodard I think what Aske meant is that you still can log into the backend through a site you don’t have access to by appending /neos to the URL. But you’ll then only see the tree of your site, so this might not be a problem for you. I’d say: just give it a try and see whether it works for you.
Just to give a feedback and also to thank you 
everything is working fine with your suggestions !
BUMP
I think this is still a very important feature for Multisites. In the User Administration module, one should be able to dynamically add the starting point(s) in the page tree for the user. Has there been any progress in the meantime? I would love to contribute, but I have no clue where to start as I am not really into Flow.
By the way, it also happened to me that the NodeTreePrivilege only grants or revokes WRITE access no nodes … sites and nodes are still visible in the page tree or Content module.
This is a related thread: Project proposal: Introduce parameterized roles
Hi Daniel,
I recently made a PR which also goes into this direction as it allows to check privileges of a user together with nodes based on a users property: https://github.com/neos/neos-development-collection/pull/1661
Hi Daniel,
I recently implemented multi-site access restrictions for two multi-site setups and have a write-up on my to do list to show how. However it doesn’t include a way to dynamically select starting points, but I believe something like that would be implemented fairly easily.
Thank you, both sounds good. I think this is a really important step for Neos and bigger website projects.
Hi @danielkestler,
Took a while to get around to it as it was quite a task to put into a easily digestible format, sorry about that.
Hi @aertmann,
thank you for this great example! Will definitely try it out!
To chime in here: it works like a charm, the AssetConstraints package has been updated for Neos 3.x by now and we packaged Aske’s solution into two small packages to help with setting up such a site.
The packages are up on Packagist already and you might be able to find them… but before doing a “proper” announcement I am giving the customer (think: sponsor) a chance to try them and give feedback. Stay tuned…
Hello everyone,
I continue in this topic: is it possible to have references in one site from content elements from another site ?
It seem’s I’ve read it somewhere, but with testing on a 3.x multisite, it seems that it’s not possible.
Or do it need some configuration anywhere ?
If I understand your question correctly, yes it’s possible, assuming the user can see what you want to render for them. In fusion I do it with test = ${q(site).parent()} so test will be the root of all sites and you can then do .find() to get what you need.
In PHP I think you can do it with context, but don’t remember exactly how.
And here is a NodeType I used to reference content across all sites:
'Vendor.Site:CrossSiteReferece':
superTypes:
'Neos.NodeTypes:Page': true
childNodes:
main: ~
ui:
label: 'Content Reference'
icon: 'icon-share-alt'
position: 210
properties:
'target':
type: reference
ui:
label: 'Target content'
inspector:
group: document
editorOptions:
nodeTypes: ['Neos.NodeType:Page'] # This is the node type you want to reference
startingPoint: '/' # This is the catch, it starts from the root
allowEmpty: falseThat’s a very nice and promising article @aertmann, thank you ! I will most probably go through it in practice since I have a use case for users in dynamic multisites.
What do you mean that your approach only supports Neos 2.x ? What would cause compatibility problems in Neos 3.x ? You mentioned to ask you or @bwaidelich about it, so that’s what I’m doing now 
Also, @kdambekalns, I would be very interested in those packages, where can I find them ?
UPDATE:
The mentioned packages are probably the following:
As noted above, they are not “officially announced” yet, I’m posting the links in order to be able to find them again later.
Thank you for sharing and thanks @christianm for helping me find them !