For instance, take this example from the classic user admin console.
Typically, this meant that we would check the root folder to give read to everyone. This is done because an AEM user can’t do much without access to “/bin” which is directly beneath the root node and you can’t directly add permissions to the bin.
This “read” would trickle down to all of the other nodes. So, when you wanted to remove access you uncheck the box, you have now added a “deny” policy.
Have you ever accidentally checked a box, saved, then unchecked? You’ve just created another deny. The only solution to remove it is to go and delete the policy. Even if you delete the user, that deny policy will persist.
Denys not only cause unnecessary clutter, but also makes troubleshooting permissions issues so much more difficult. This was a very unclean approach that we adapted to. Now, we have a better option in AEM to manage permissions.
This “read” would trickle down to all of the other nodes. So, when you wanted to remove access you uncheck the box, you have now added a “deny” policy.
Have you ever accidentally checked a box, saved, then unchecked? You’ve just created another deny. The only solution to remove it is to go and delete the policy. Even if you delete the user, that deny policy will persist.
Denys not only cause unnecessary clutter, but also makes troubleshooting permissions issues so much more difficult. This was a very unclean approach that we adapted to. Now, we have a better option in AEM to manage permissions.
Touch UI Permissions Console
With the introduction of the Touch UI Permissions Console, you can now set your policies for your Principals. You also have the option of creating exceptions easily through the UI.
Utilizing the example from before, this is how it looks in the permissions console.
![]()
![]()
You still have the “read” on the root, but now you can create a glob on that node. Rep:glob=”” sets the read permissions to itself only. This means any nodes directly tied to root will be readable but subfolders will be excluded and will not inherit read. This gives you more control over what permissions you need to set without having to worry about “accidental” permissions.
I did the same thing on “/content” because authors will get permissions to specific areas through other groups. Again, no need to create a deny.
Although this isn’t a true Principal Authorization implementation, since under the hood it’s still creating the policies for the paths, it’s a big step forward for managing permissions on a more granular level.
Read more about this on the Adobe website.
With the introduction of the Touch UI Permissions Console, you can now set your policies for your Principals. You also have the option of creating exceptions easily through the UI.
Utilizing the example from before, this is how it looks in the permissions console.
You still have the “read” on the root, but now you can create a glob on that node. Rep:glob=”” sets the read permissions to itself only. This means any nodes directly tied to root will be readable but subfolders will be excluded and will not inherit read. This gives you more control over what permissions you need to set without having to worry about “accidental” permissions.
I did the same thing on “/content” because authors will get permissions to specific areas through other groups. Again, no need to create a deny.
Although this isn’t a true Principal Authorization implementation, since under the hood it’s still creating the policies for the paths, it’s a big step forward for managing permissions on a more granular level.
Read more about this on the Adobe website.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.