Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

When deleting a resource, should the corresponding ACL document also be deleted? #187

Closed
michielbdejong opened this issue Jun 5, 2019 · 7 comments

Comments

@michielbdejong
Copy link
Contributor

In other words, would nodeSolidServer/node-solid-server#1180 be a violation of the spec?

@michielbdejong
Copy link
Contributor Author

This is a complicated topic, related to #172.

A cleaner solution would, I think, be to say ACL documents should just show up in container member listings?

@michielbdejong
Copy link
Contributor Author

@jaxoncreed what do you think of the solution where acl docs show up as container members so that it's not such a pain to guess their paths when trying to delete a container (in other words, give the app the ability to see whether a container is empty or not, and if not, which members still exist)

@jaxoncreed
Copy link

@michielbdejong I personally don't like it. I think that .acl files are essentially metadata and not documents themselves. I can see how this becomes easier for certain operations like delete, but other operations would require you to differentiate between acl files and regular ones for access control. Plus, I think it would be confusing on the user's end.

@RubenVerborgh
Copy link
Contributor

I think that .acl files are essentially metadata and not documents themselves.

The spec does not support that interpretation though. Quite the contrary: ACL files are RDF documents, that can contain arbitrary triples. The only differences are that a) some of those triples will determine access control to other documents and b) viewing or editing them requires Control permissions instead of Read or Write.

@jeff-zucker
Copy link
Member

How about the equivalent of ls -al? In other words .acl and .meta are invisible to a regular GET on a container but visible with a special GET?

Or on a different track : always delete all .acl and .meta when deleting an otherwise empty container. This would prevent the current possibility of undeletable containers filled with undiscoverable .acl files.

@humont
Copy link

humont commented Aug 17, 2019

For what it's worth, in my current implementation I treat a DELETE request to a container as acceptable if the container if all it contains are it's own .acl and .meta file - I did pause to reflect at the time of implementing, but it struck me as an intuitive way of going forward.

Given that .acl and .meta files are not files with which a user will routinely interact, requiring the user to delete them (or throwing an error when the user attempts to delete a container which stll contains them) seems like it would produce additional friction to the UX in a way that is not immediatley transparent.

In line with this, I am currently parsing a DELETE request for a resource by fetching any "describedBy" and "constrainedBy" files that concern only it (quite easily verifiable by traversing the graph contained within these files).

@dmitrizagidulin
Copy link
Member

Semi-duplicate of solid/solid#251

Will be tackled in solid/specification#58, closing this one.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants