OOTB Audit Log shows only addition or modification of Users or Groups. How can we log Permission details once we update permission navigating to http://localhost:4502/security/permissions.html or using CRXDE Access Control Tab ?
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @Bhuwan_B!
Citing from my reply on this thread:
Please check the following documentation:
[...]
I double checked and can confirm the behavior differs from the documentation [...].
After checking it seems that you need to raise the log level to "DEBUG" and add another entry to the "Logger" section of the OSGI configuration:
com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet
This will at least give you some basic logging on permission management, such as:
*DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin adds policy on /content/dam for test
*DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin removing policy for /content/dam, [759448319_, 759448319
Hope that helps!
Try creating event listener on /home/users node and create a custom log file for any changes in ACL under this node structure.
Unfortunately, the listener approach will probably not lead to the desired result. If you give a user additional permissions, e. g. to read or edit a certain repository path, this will be stored on the according path and it's rep:policy node-structure. There will be no change to the user node below /home/users (unless you perform additional changes on the user), especially nothing with regards to the users permissions will change here or is tracked in the user nodes. So a listener on /home/users will only track permission changes on user nodes (which are usually not changed very often apart from user creation or deletion), not if you change permissions for any other part of the repository.
As a side note: Even if this would be the case and permissions would be stored on the according principal nodes (which they are not), it would still not be a good idea to set permissions on user level. Permissions should always be managed on group level and users get them through assigned group memberships.
Views
Replies
Total Likes
Hi @Bhuwan_B!
Citing from my reply on this thread:
Please check the following documentation:
[...]
I double checked and can confirm the behavior differs from the documentation [...].
After checking it seems that you need to raise the log level to "DEBUG" and add another entry to the "Logger" section of the OSGI configuration:
com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet
This will at least give you some basic logging on permission management, such as:
*DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin adds policy on /content/dam for test
*DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin removing policy for /content/dam, [759448319_, 759448319
Hope that helps!
Views
Likes
Replies