Access security

[wouterj]

If I don't miss something, this bundle allows everyone to request the API URLs. At this moment, it means one can retrieve all tree information, even from nodes that shouldn't be showed to other people.

Besides that, when we implement more things than just GET (#6), even more things will be provided to the hacker.

[dantleech]

Yes, at the moment all of the configured resource trees are available. We would need to configure which ones are exposed and also think about how to filter what is made available.

Of course all of this should normally be behind a firewall.

[dbu]

maybe the controller should by default check for isGranted CMF_RESOURCE_READER and CMF_RESOURCE_EDITOR to at least not expose things when the bundle is accidentally dropped into a project.

[lsmith77]

I also see this as mainly a job for the firewall to cover. Once we add write support we should make sure that we can handle the different operations using isGrant checks.

[ElectricMaxxx]

I would also add to the "global" CMF_RESOURCE_READER" some constructed roles as sonata does. i.e. when having a resource with paht/cms/content/collection/name" i would see the following roles to check for:

• CMF_RESOURCE_CMS_CONTENT_COLLECTION_NAME_VIEW
• CMF_RESOURCE_CMS_CONTENT_COLLECTION_NAME_EDIT
• CMF_RESOURCE_CMS_CONTENT_COLLECTION_NAME_DELETE
• CMF_RESOURCE_CMS_CONTENT_COLLECTION_CREATE

so you wil have a control to every kind of resource in the tree.

[dbu]

so you would translate the whole path to role names? with deep path, this could end up in a lot of role checks. imho that would just be duplicating what you can do with the firewall.

i think the way to go further would be custom security voters that can look at whatever application specific things (document type, information in the phpcr tree) to decide. which means the controller could ask with the document in question as well. maybe only ask with that, and have a security voter that checks for the CMF_RESOURCE_READER/EDITOR role.