Skip to content
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

Append mode creation of resource should work as well with PUT #122

Closed
timbl opened this issue Oct 15, 2023 · 3 comments · Fixed by #123
Closed

Append mode creation of resource should work as well with PUT #122

timbl opened this issue Oct 15, 2023 · 3 comments · Fixed by #123

Comments

@timbl
Copy link

timbl commented Oct 15, 2023

The text about mapping access modes to HTTP methods

In "NOTE: HTTP Method and Access Mode Mapping" in
https://solid.github.io/web-access-control-spec/#reading-writing-resources
says

The HTTP POST can be used to create a new resource in a container or add information to existing resources (but not remove resources or its contents) with either acl:Append or acl:Write.

As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode would be required.

It should say

The HTTP POST can be used to create a new resource in a container or add information to existing resources (but not remove resources or its contents) with either acl:Append or acl:Write.

As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode is required to replace an existing resource, but to create a new resource, access to the container can be either acl:Append or acl:Write.

This is because it is essential that the semantics of the mode of access are about what the agent can do with the resource, independent of which HTTP method (or other protocol for that matter) they happen to be using.

(As we have already ensured for PATCH, for example.)

@csarven
Copy link
Member

csarven commented Oct 15, 2023

Thanks. That's useful for the Note. PR #123 (using the text as suggested in this issue) is a solution to resolve this issue.

@damooo
Copy link

damooo commented Oct 15, 2023

This is because it is essential that the semantics of the mode of access are about what the agent can do with the resource, independent of which HTTP method (or other protocol for that matter) they happen to be using.

That's great. It also helps implementations for much robust architecture. For eg, Manas has an abstraction called Repo, that provides services to perform authorized operations on resources. They can be used independently, or from http method handlers.

@csarven
Copy link
Member

csarven commented Oct 15, 2023

I agree but once again, this has been the case all along. It is precisely why the there is a "mapping" Note. Moreover in https://solid.github.io/web-access-control-spec/#http-interactions :

Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, e.g., [SOLID-PROTOCOL], [LDP], [ACTIVITYPUB].

michielbdejong added a commit to michielbdejong/web-access-control-spec that referenced this issue Dec 6, 2023
This updates the text to match what we decided in solid#105 (comment). At the time we decided not to update the spec text, but now that the spec text is more detailed, the current statement is not correctly conveying that access to both the containing folder and the non-existing resource URL is required.

See the confusion that was created by this in solid-contrib/web-access-control-tests#56 which was an (I think incorrect) reaction to solid#122.
csarven added a commit that referenced this issue Dec 15, 2023
)

* Further clarify requirements for PUT-to-create and PATCH-to-create

This updates the text to match what we decided in #105 (comment). At the time we decided not to update the spec text, but now that the spec text is more detailed, the current statement is not correctly conveying that access to both the containing folder and the non-existing resource URL is required.

See the confusion that was created by this in solid-contrib/web-access-control-tests#56 which was an (I think incorrect) reaction to #122.

* Apply suggestions from code review

Co-authored-by: Ted Thibodeau Jr <[email protected]>

---------

Co-authored-by: Sarven Capadisli <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants