-
Notifications
You must be signed in to change notification settings - Fork 44
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
What does a Write operation imply #126
Comments
There are somewhat similar considerations to Read eg. #116 (comment) discuses privacy as per containment listing in that the observability of a resource is uniform. [Aside (oh you may like this analogy): while a resource may not be observable, attempting to delete a container and failing in the absence of Read access may partly hint at the possibility that something exists. Just like a blackhole and how it bends light passing by :)] |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
So, I'm trying to think in terms of sufficient conditions and recursive definitions. Don't know if I'm succeeding. :-) But how about something like
The append case should then be covered by the similar but stricter conditions in #118. |
We should take care to not introduce a new definition in this issue but okay that if it can help to articulate the notion. Clarifying the relationship between HTTP and WAC would be pragmatic as in https://www.w3.org/wiki/WebAccessControl#WAC_relation_to_HTTP_Verbs Write is an update in that information can be created or removed, and categorically excludes operations to "read", as well as unintended exposure or side-effects within that. A write operation affects a set resources atomically and recursively. For example:
With respect to HTTP verbs that are intended for writing, POST, PATCH, PUT and DELETE can be used for the purpose of write. In the case of PATCH, acl:Write would not allow the WHERE clause (re "unintended exposure or side-effects"). |
Ibid, #118 , I'd say :-) So, we need to write the normative text, but we have pretty much the same understanding. Rough consensus? |
From several discussions, we are starting to rely on side effects to update certain resources, especially containment triples.
This opens the question: What is really a write operation?
It is pretty clear that when you write to a resource, that's a write operation. It gets more unclear when there are updates done by the server as a side effect.
We could adopt the interpretation that if the state of a resource
Q
is altered by an operation on a different resourceR
, that operation requires write privileges on that resourceQ
, even if itR
is the resource identified by the request-URI.One implication of this idea is for example that deleting a resource
R
requires write privilege on the containerC
, since it requires updating the containment triples.The text was updated successfully, but these errors were encountered: