The goal of this project is it to make it a lot easier to debug your ACL and Policy.yaml. Right now there is no intutive way to get some feedback if a PrivilegeTarget matches on a node or not and for wich user and so on. If you set up a more complex Policy.yaml it can be a pain in the ass and take a lot of time to get everything figured out.
This project is about a new backend module to inspect your ACL settings. This is not about creating or editing any privliege targets, user or user roles.
Background
At the sprint before InspiringCon i worked with @bwaidelich on a new PrivilegeTarget (https://github.com/neos/neos-development-collection/pull/477) and it was was really aweful to debug this because there is no real indication what matchers really kick in. So we came up with this idea to make this a lot easer.
###Value
Helps Adminstrators to check their user/roles against their nodetree
Makes debugging a lot easier when you set up a Policy.yaml
###Risks
none since it can be easily included as a standalone package and shouldn’t be to hard at all to implement since all the logic is already there
##How to start?
We’d like to start discussing on a possible GUI in iterations so that we can come up with a very easy to use interface that covers the most important scenarios. For this i created a small Prototype:
I just included the latest neos css styles and started to create a simple hacky form to have something to start with.
So i think we need some filter splitted in two parts. On the one hand to limit the nodes. This could be either by path, nodetype and dimension. On the other hand we need to select for wich users or groups the nodes should be evaluated. And also make it possible to see the final result for a special prvilege target. So if you implement a new privilege target you could easily check this one and a user or role and check if the nodes are denied or granted etc.
The nodetree itself is right now just a simple table but could also be a dynamic tree. There should be important informations like nodepath, nodetype, nodetree access, read access, edit access and create access. Also the result for the filtered privlege targets would fit there.
So guys, what do you think? How could such a module look like? What do we miss here? As soon as we commit on this draft we can start prototyping! Let’s discuss and send in some PR’s to get this thing alive
I think this could be very well a part of the base distribution when you install Neos.
Very nice for admins and not only for debugging.
Two things that come to my mind are autocompletion for the path and pagination or something which keeps the module from loading 1000 nodes.
I think I would usually like to see a node and it’s parents.
Should also be possible to debug! At least you can grant/deny single nodetypes so they should be reflected.
i totally agree about pagination. Could maybe also handled with a dynamic tree and we load the childrens if you collapse? Just like the nodetree and structure tree does?
I only have a small addition to make: I’d make the UI a little more “explanatory”, i.e. add some more help texts. I could also imagine that we are able to strip down the UI in a “Basic” and an “Advanced” mode; i.e. I could imagine in “Basic” mode I can just select a user. Then I see for the user, which roles it has, which privilege targets they map to, and how it applies on the tree. (Or s.th like this).
@stolle looks awesome, thanks for starting with a mockup
I would suggest to do this iteratively and start with the simplest (to use) thing possible:
The Role-Selector + a table of all Document nodes with the icons for the built-in privileges (NodeTree, ReadNode, EditNode, CreateNode, …) and extend it from there. Wdyt?
Yup! That’s the way i wanted to get started. The GUI prototype is just to get a feeling about the direction it could move. Whatever, i started a first prototype. Guess we have to talk about almost all the class names and stuff. But this is just a pretty rough first prototype
Hey @dfeyer won’t stay like this. Just a first very very rough implementation to get some nodes at all. Guess when it’s finished there will be couple ways to filter nodes. start -> end, end and everything upwards as @sebobo mentioned, start + x levels and so on.
We will iterate over and over and put more stuff in it.
Also i could imagine a pagination support and/or dynamic tree to show/filter nodes
Just a small heads up:
After some discussions with @mgoldbeck and @bwaidelich we came up with some next steps. First step is to show the full tree on the first view and implement a detail view for a node with a bunch of more details.
So right now this is the current state that is pushed:
By default the the full tree depending on the TYPO3.Neos.userInterface.navigateComponent.nodeTree.loadingDepth will be shown. Next step will be a first draft for a detail view with PrivilegeTargets etc.
The detail view provides some more informations. Some basic stuff on the right side. On the left are some accordeons with your Privilege Targets. Denied, Abstained and Granted targets that match the current node are listed here! There is also a small breadcrump at the top. You can navigate to those nodes by clicking them.
Below that you got a tree with all your content on that node. If there are more than 2 roles a show all button will be displayed for now because the list is just to big if al roles are rendered in that result list:
Awesome work! This already works great and it will help a lot of devs struggling with ACLs.
A couple of “issues” I stumbled upon (I’m sure you’re aware of them mostly, but I’ll lest them anyways - even some nitpicks):
The composer name of this package is johannessteu/neos-aclinspector but it sits in the Neos\.. Namespace, which is reserved for core package. At least for the moment I’d suggest to keep it in your namespace or move the package to flowpackage/neos-aclinspector
And then a couple of stumbling block regarding the UI:
The Roles checkboxes don’t remember their state when submitting the filter, and the default selection (TYPO3.Neos:Editor & TYPO3.Neos:Administrator) is not reflected
The filter form should IMO be sent via GET, so one could send deep-links
The icons on top of the “Access Control List”-table stand for create, edit, delete, show in tree I suppose, but that’s not very self-explanatory
The tick-icons don’t seem to work for me. I have Read-, Edit- and CreateNodePrivileges applied to the “Member area” subtree, but everything is green:
This is fine in this very easy example, but I still have to compute the different abstains and grants and such… and it doesn’t show which privileges are behind those names. I’d like to immediately see which role is allowed to do what and then have a way to figure out why that is
