Deny Access to a Folder
Important note when using the walkthroughs
When the walkthroughs refer to some yaml configuration, in general, it is meant that you import this yaml into a locally running repository via the Console with auto-export enabled. If however you copy some yaml blob directly into your idea without auto-export, you have to uncomment the following lines if present in the yaml:
#.meta:category: system #.meta:add-new-system-values: true
The reason for this is that the auto-export for some properties knows implicitly to add this meta info, however the yaml import in the Console does not support .meta lines. Thus, you have two options when following the walkthroughs:
- Copy the yaml snippet as-is into the Console with auto-export running
- Copy the yaml snippet to your idea while uncommenting the commented meta info
Deny a group access to a specific folder in the content repository.
Such a project contains two root content folders:
Contains the news articles.
Contains resource bundles to manage static labels on the website.
By default the 'editor' group has editor privileges on both folders, and the 'author' group has author privileges in both folders.
Below is documented how you can
- Deny the 'author' group all access to /content/documents/administration
Optionally grant the 'author' group read-access to /content/documents/administration : this is useful when for example the administration folder contains documents like selection:valuelist which typically are used in pickers when editing a document: You want authors to be able to use these selection list documents when editing a document, so they need read-access selection list documents below administration, but they are not allowed to modify them.
There are multiple ways to achieve the above use case. We'll document below the easiest approach, however per use case detail, you might want to configure it differently. For example, there are also use cases where you rather introduce new groups or even new userroles.
To be able to deny access to the administration folder you will customize the Default Authorization Setup as follows:
- Exclude the administration folder from the default content domain at /hippo:configuration/hippo:domains/content.
- Define a new domain hippo:configuration/hippo:domains/content-administration that includes only the administration folder.
- Assign the 'editor/admin' group editor/admin privileges on the content-administration domain.
- Optionally: Give the author group readonly access to content-administration domain
Customize Security Domains
Exclude the Folder from the Default Content Domain
Log in to the Console as 'admin' and make sure that Autoexport is on.
At /hippo:configuration/hippo:domains/content/content-domain add a new facet rule exclude-administration (you can copy paste below and use YAML import on the node content-domain)
/exclude-administration: jcr:primaryType: hipposys:facetrule hipposys:equals: false hipposys:facet: jcr:path hipposys:type: Reference hipposys:value: /content/documents/administration
The above extra facetrule makes sure that the default /hippo:configuration/hippo:domains/content domain does not match /content/documents/administration and descendants any more. This means that not only users with userrole xm.content.author are affected, but also users with userroles
If we'd only apply the above, also the group editors wouldn't be able to see (read) the /content/documents/administration any more, and the group admin wouldn't have hippo:admin privilege any more (they can read because group admin can read everywhere). Therefore, we need to grant the right privileges again for /content/documents/administration to the userroles above. This can be done a follows:
Create a New Domain for the administation folder
At /hippo:configuration/hippo:domains add a new security domain:
/content-administration: jcr:primaryType: hipposys:domain /content-domain: jcr:primaryType: hipposys:domainrule /administration: jcr:primaryType: hipposys:facetrule hipposys:equals: true hipposys:facet: jcr:path hipposys:type: Reference hipposys:value: /content/documents/administration /editor: jcr:primaryType: hipposys:authrole hipposys:groups: #.meta:category: system #.meta:add-new-system-values: true type: string value:  hipposys:role: editor hipposys:userrole: xm.content.editor hipposys:users: #.meta:category: system #.meta:add-new-system-values: true type: string value:  /admin: jcr:primaryType: hipposys:authrole hipposys:groups: #.meta:category: system #.meta:add-new-system-values: true type: string value:  hipposys:role: admin hipposys:userrole: xm.content.admin hipposys:users: #.meta:category: system #.meta:add-new-system-values: true type: string value: 
After saving the above changes, validate with the View Permissions Dialog in the Console that an author user doesn't have any permission/privilege on /content/documents/administration while an editor user has the same permissions/privileges as on /content/documents/myproject.
Optionally: Grant read access to group authors
As explained above, when the /content/documents/administration contains documents like selection:valuelist which are used in pickers when editing documents below /content/documents/myproject, then most likely the author group still needs read access to /content/documents/administration. This can be easily achieve by realizing that the author group has the userrole xm.content.viewer which can be used to give readonly access. By adding the below configuration to /hippo:configuration/hippo:domains/content-administration, everybody in group author will get read access to /content/documents/administration and descendants:
/readonly: jcr:primaryType: hipposys:authrole hipposys:groups: #.meta:category: system #.meta:add-new-system-values: true type: string value:  hipposys:role: readonly hipposys:userrole: xm.content.viewer hipposys:users: #.meta:category: system #.meta:add-new-system-values: true type: string value: 
Make sure that after all the above changes everything is synced with auto-export to your local project : doing the above on production involves the risk that on new deployments the changes are overridden since this part of the security domains is config.