Hi,
I'm new to permission (ACL) management in AEM, and I need your help in setting permissions properly.
Here are some basic infos:
Example site structure:
- project
-- us
--- en
---- products
----- item1
----- item2
----- item3
---- about-us
-- fr
--- fr
---- products
---- about-us
Example group structure:
- content-authors (a big group for authoring contents)
-- groupA (responsible for authoring "project/us" and below)
-- groupB (responsible for authoring "project/fr" and below)
-- groupC (responsible for authoring "project/us/en/products" and below)
To be concise, every group should not able to read other directories (e.g. "project/fr" is not visible to groupA).
In above case, how should I set permissions for groupA, B, and C?
I've read that rep:glob restrictions can help us set flexible, fine-grained permissions but I don't have any idea how to implement that. [2] shows how to set restrictions in the console, but it doesn't tell me this-will-do-what.
Could you guide me step by step?
Thanks in advance ![]()
I've also checked these docs/tips out:
[1] https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/security.html?l...
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
I managed to set the permissions for the destination paths by adding a simple Allow jcr:read statement:
Allow | jcr:read | (No restrictions)
e.g.
project/us/en/products | Allow | jcr:read | (No restrictions)
As for intermediary paths like "project" and "project/us/en", add these two to each path:
Allow | jcr:read | rep:glob=""
Allow | jcr:read | rep:glob="/jcr:content/*"
e.g.
project/us/en | Allow | jcr:read | rep:glob=""
project/us/en | Allow | jcr:read | rep:glob="/jcr:content/*"
This will let them pass to the destination path in the Sites Console while other unintended subtrees are unseen.
I will close this case since it's resolved ![]()
Thank you for your kind comments, @arunpatidar and @markus_bulla_adobe !
Hi @akaria!
Using globbing in permission management is a powerful technique but often a bit tricky and hard to get right.
As someone from "the old days" I still refer to CRX Explorer and it's ACE Editor to prototype and test my permission setups, especially when it comes to globbing.
For actual management and deployment of permissions, I recommend to not manage them manually but to leverage Netcentrics ACL Tool that allows you to define your groups and permissions in a yaml syntax and deploy them consistently along with your application code to all your environments.
Coming back to your question about globbing (rep:glob), you may want to check the Oak documentation on this topic as it comes with a couple of examples that can help you understand how globbing works.
Hope that helps!
Views
Replies
Total Likes
Hi,
As already mentioned by @markus_bulla_adobe , how to use rep:glob but in your case you don#t have to use it,
you can esily set the permission of more restricted group to restricted path
e.g
set read for permission for groupA at /content/project/us
set read for permission for groupB at /content/project/fr
set read for permission for groupC at /content/project/us/en/products
No need to use rep:glob or rep:restriction
Views
Replies
Total Likes
I managed to set the permissions for the destination paths by adding a simple Allow jcr:read statement:
Allow | jcr:read | (No restrictions)
e.g.
project/us/en/products | Allow | jcr:read | (No restrictions)
As for intermediary paths like "project" and "project/us/en", add these two to each path:
Allow | jcr:read | rep:glob=""
Allow | jcr:read | rep:glob="/jcr:content/*"
e.g.
project/us/en | Allow | jcr:read | rep:glob=""
project/us/en | Allow | jcr:read | rep:glob="/jcr:content/*"
This will let them pass to the destination path in the Sites Console while other unintended subtrees are unseen.
I will close this case since it's resolved ![]()
Thank you for your kind comments, @arunpatidar and @markus_bulla_adobe !