-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unsufficient restriction over user supplied containment triples #451
Comments
[1] Whether and how the server should process that particular payload is unspecified. Hence, servers are neither required to accept the request; to further create new resources based on the containment statements in the payload; to include those containment statements in the description of the newly created resource (but without creating the contained resources as described in the payload), or; anything else for that matter. Furthermore: if the intention of the request is to create a non-container resource, then the containment statements in the payload are invalid use of If the request is to create a container as a member of another container (i.e., the target of the POST request) and includes a payload with containment statements, then [1]. (I couldn't resist the circular explanation :)) |
As most implementations doesn't prefer(?) to allowing arbitrary containment triples and creating resources, and clients expect all ldp::contains statements in a container rep are server managed and valid, it may be better to specifying that, so that all can point to same requirement. Just like PUT and PATCH are specialized against target resource in above requirement like |
I agree with @damooo . Allowing folders to have arbitrary Currently, most applications I've checked implicitly trust the contain statements, leading to unexpected behaviour if this is not the case. For instance, several recursive delete methods I've seen simply proceed to delete all contained resources, without checking their urls. If the folder "contains" files with completely different urls, the applications will happily delete them too. This is for sure unexpected behaviour, even with security implications. We may argue, that it is up to the applications to check this. However, I don't see why we should not add this constraint, as we already have similar constraints for PUT and PATCH. Except of course, that this change would not be backwards compatible and eg ESS would need to change their implementation. |
Currently following requirement is the only one that restricts user supplied containment triples.
But that allows including containment triples in representation of
to be created
container, when container is created throughPOST
on parent container.It may not be the intention.
The text was updated successfully, but these errors were encountered: