You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Return 'wac-allowed' HTTP header with GET & HEAD responses #246
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:
WAC-Allow: user="read", public="read"
Doing an HEAD request (while authenticated) to a resource you have full read/write/control access to:
WAC-Allow: user="read;write;control", public=""
(Note the public="" part -- the empty string denotes no access.)
changed the title [-]Support `Access-Control-*-Methods` semantics for pre-flight requests[/-][+]Implement ACL checks for the `Allow:` header[/+]on Feb 24, 2016
changed the title [-]Implement ACL checks for the `Allow:` header[/-][+]Return 'wac-modes-allowed' HTTP header with GET & HEAD responses[/+]on Jan 4, 2017
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
Activity
dmitrizagidulin commentedon Feb 24, 2016
Updated issue to use
Allow:header instead of CORSAllow-Methods[-]Support `Access-Control-*-Methods` semantics for pre-flight requests[/-][+]Implement ACL checks for the `Allow:` header[/+]rhiaro commentedon Apr 7, 2016
+1
[-]Implement ACL checks for the `Allow:` header[/-][+]Return 'wac-modes-allowed' HTTP header with GET & HEAD responses[/+]dmitrizagidulin commentedon Jan 4, 2017
Updated to use a custom
WAC-Modes-AllowedHTTP header instead ofAllow(which sounds like isn't appropriate for authentication-related matters).dmitrizagidulin commentedon Feb 6, 2017
Updated it to reflect today's design discussion; return both the permissions of the user, and public permissions.
[-]Return 'wac-modes-allowed' HTTP header with GET & HEAD responses[/-][+]Return 'wac-allowed' HTTP header with GET & HEAD responses[/+]Expose the user's permissions through a header.
RubenVerborgh commentedon Aug 17, 2017
Implemented by #550.
Expose the user's permissions through a header.
Expose the user's permissions through a header.
Expose the user's permissions through a header.
Expose the user's permissions through a header.
Expose the user's permissions through a header.
Expose the user's permissions through a header.