-
Notifications
You must be signed in to change notification settings - Fork 45
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
Discoverability of supported update methods on resources without read permission #497
Comments
To make the question more precise: following this part of the spec, are servers supposed to return Accept-Patch, Accept-Post, or Accept-Put headers, when the client does a HEAD/GET request and the server replies with a 401 Unauthorized error, if that client only has write/append permissions (so no read)? |
The
As mentions above, requirements reading resources and communication options are in https://solidproject.org/ED/protocol#reading-resources (allowed HTTP methods and media types).
Clients should not expect the server to include the If you're satisfied with the responses, can we close the issue? We can update the Solid Protocol to clarify clients finding access permissions. You're also welcome to ask questions in chat: https://gitter.im/solid/specification . Note the upcoming move from Gitter->Matrix: https://gitter.im/solid/specification?at=63d817920c94855213d77fb4 |
I'll join in here as this issue is a consequence of some questions about CSS behaviour. This does already answer the question of whether the
Is this an example of what the unauthenticated client would receive on an OPTIONS request? The reason that I ask is because that was the initial question, but this response contains So specifically, if a client only has |
As per https://solidproject.org/ED/protocol#server-accept-headers , the server includes No auth is expected for CORS-preflights. Server can include the |
My apologies if it might seem that I'm being difficult, but I want to make sure I'm fully correct about the details. I might have also caused some confusion due to not taking the "authorized request" part into account, so I'll ask some very specific questions. (I also just noticed I used What exactly is an "authorized request"?
My guess is the first option, but I want to make sure. Are the contents of the
|
No need to apologise. You're not being difficult. I take it as input to consider improvements. It partly follows #378 (comment) , so thanks for asking. All, please interpret the following as what's intended with the wording of the current text. Implementation feedback, corrections, and other considerations are welcome.
Generally a 2xx, and especially not a 401/403.
That doesn't guarantee an authorised response.
Yes.
Currently yes.
To be clear, an "authorized OPTIONS request" entails that the request was not a CORS preflight request. Regarding the role of 405 or 501, see #353 (comment) .
I find the first to be most accurate and useful but let me respond this way: The HTTP methods listed by the When a response to Happy to try to further clarify the above. Once clear and there are no technical objections, I can look for ways to clarify the Solid Protocol. [1] Some of the underlying considerations are categorically the same as in #311 or maybe just philosophical ramblings. [2] |
I also found #378 (comment) while searching for an answer, and assumed that the implication was that the authorization header should be used to determine if a request is a preflight request or not, but perhaps I misinterpreted that. The CORS library that CSS uses actually assumes that all OPTIONS requests are preflight requests, so we will need to disable that behaviour and have our own custom check. Checking the presence of the My current interpretation of the expected server behaviour for an OPTIONS request is then:
Is this correct? If yes, how do you authorize an OPTIONS request? Going back to #14 (comment) which I originally used to implement responses for the status codes the assumption is that the same permissions as for a GET/HEAD request should be used? So If the answer to the previous question is no this can be ignored, but if it is yes, then the original issue of this thread becomes a problem again. Specifically: there is a container where you only have append/write permissions on. How do you know that you can send data there and what the format of that data should be? Since you can't do an OPTIONS request to determine the |
This is not necessarily an issue, but more of a request for clarification inspired by an actual use case - whether misuse or valid, I do not know, hence why I am asking. If this is not the correct place to ask, I would appreciate any pointers to the appropriate location.
Are there any guidelines in the specification for how a client can discover supported update methods (or, in general, any write/delete/append support) on resources on a Solid server, when the client has write or append permissions but no read permission?
An example use case could maybe be an inbox, to which everyone has append permission but only the owner has read permission. So whenever a client wants to write to that inbox, the client would either know that the server supports specific types or updates (or updates in general) or just blindly send some form of update and hope it works.
Is there an existing way for a client to determine whether they can do updates on a resource without read permissions? Or if there is no way for a client to do that (without trying an update first), could something be done with response headers to indicate support for updates without read permission?
I tried to look through the open issues, but did not find anything addressing that.
Thank you in advance for your time, and apologies if this has been answered before.
The text was updated successfully, but these errors were encountered: