Repository navigation
Return 'wac-allowed' HTTP header with GET & HEAD responses #246
Description
Activity
Updated issue to use
Allow:header instead of CORSAllow-Methods- changed the title
[-]Support `Access-Control-*-Methods` semantics for pre-flight requests[/-][+]Implement ACL checks for the `Allow:` header[/+]on Feb 24, 2016 +1
- changed the title
[-]Implement ACL checks for the `Allow:` header[/-][+]Return 'wac-modes-allowed' HTTP header with GET & HEAD responses[/+]on Jan 4, 2017 Updated to use a custom
WAC-Modes-AllowedHTTP header instead ofAllow(which sounds like isn't appropriate for authentication-related matters).Updated it to reflect today's design discussion; return both the permissions of the user, and public permissions.
- changed the title
[-]Return 'wac-modes-allowed' HTTP header with GET & HEAD responses[/-][+]Return 'wac-allowed' HTTP header with GET & HEAD responses[/+]on Aug 16, 2017 - added a commit that references this issue
on Aug 17, 2017 Implemented by #550.
- added 5 commits that reference this issue
on Aug 17, 2017 - added a commit that references this issue
on Aug 18, 2017
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
.aclfiles 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.)