-
Notifications
You must be signed in to change notification settings - Fork 304
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
Return 'wac-allowed' HTTP header with GET & HEAD responses #246
Comments
Updated issue to use |
dmitrizagidulin
changed the title
Support
Implement ACL checks for the Feb 24, 2016
Access-Control-*-Methods
semantics for pre-flight requestsAllow:
header
+1 |
dmitrizagidulin
changed the title
Implement ACL checks for the
Return 'wac-modes-allowed' HTTP header with GET & HEAD responses
Jan 4, 2017
Allow:
header
Updated to use a custom |
Updated it to reflect today's design discussion; return both the permissions of the user, and public permissions. |
dmitrizagidulin
changed the title
Return 'wac-modes-allowed' HTTP header with GET & HEAD responses
Return 'wac-allowed' HTTP header with GET & HEAD responses
Aug 16, 2017
RubenVerborgh
added a commit
that referenced
this issue
Aug 17, 2017
Implemented by #550. |
RubenVerborgh
added a commit
that referenced
this issue
Aug 17, 2017
RubenVerborgh
added a commit
that referenced
this issue
Aug 17, 2017
RubenVerborgh
added a commit
that referenced
this issue
Aug 17, 2017
RubenVerborgh
added a commit
that referenced
this issue
Aug 18, 2017
RubenVerborgh
added a commit
that referenced
this issue
Aug 18, 2017
dmitrizagidulin
pushed a commit
that referenced
this issue
Aug 18, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem/Motivation
There is currently no easy way for solid client code to determine if the current user has read/write/delete etc access to a given resource (short of reading and parsing the ACL chain, which is both discouraged, and not always possible due to ACL limitations on the
.acl
files themselves). (See solid/#45 - No way to find out if user is authorized to write to a container for context.)Proposed Solution
An easy solution to this would be to add support to LDNode for the following:
With every response, the server should include an additional
WAC-Allowe:
header in the HTTP response.For example, doing an unauthenticated HEAD request on a public read-only resource, would yield:
Doing an HEAD request (while authenticated) to a resource you have full read/write/control access to:
(Note the
public=""
part -- the empty string denotes no access.)The text was updated successfully, but these errors were encountered: