For example, if you need to grant permission to view and edit pages only under a specific subpage tree of the repository, apparently it could be an easy task to do but it would eventually reveals hard to arrange.
Let’s try to schematically represent a repository structure to analyze:
→ content
→ projectA
→ en
→ SubHome1
→ Subhome2
→ Article1
→ Article2
→ Article3
→ it
→ projectB
→ projectC
Our goal is to provide a full access to SubHome2 page and all its children, not allowing to see other pages (i.e. SubHome1, it language, etc..).
It would have been easy to grant a jcr:all privilege to SubHome2 but Adobe AEM tools are based on path browsing, consequently, all folders composing the requested path must be visible to get access.
In the bullet list above in fact, we can distinguish:
- Green: Pages with full access
- Orange: Pages with a partial read access (basically only the cq:Page and cq:PageContent nodes)
- Gray: Pages not visible
PATH
|
PRIVILEGES
|
RESTRICTION
|
NOTE
|
/
|
ALLOW jcr:read
|
rep:glob=
|
Read permission to root node only
|
/content
|
ALLOW jcr:read
|
rep:glob=
|
Read permission to content node only
|
/content
|
rep:readProperties
|
Read permission to node properties (needed for CRX navigation)
| |
/content
|
ALLOW jcr:read
|
rep:glob=/*/jcr:content
|
Read permission to see jcr:content node (for page properties)
|
/content/projectA
|
ALLOW jcr:read
|
rep:glob=
|
Read permission to projectA node only
|
/content/projectA/en
|
ALLOW jcr:read
|
rep:glob=
|
Read permission to EN node only
|
/content/projectA/en/SubHome2
|
ALLOW jcr:all
|
Full access to node section
|
View table on plain text formatHint: To set an empty rep:glob value fill the input field with two double quotes (“”)
Once done final user will be able to use all standard AEM tools and properly manage his area, preserving resources outside of his focus range
No comments:
Post a Comment
If you have any doubts or questions, please let us know.