search

RubenVerborgh / solid-architecture

Drafts on the intended architecture of a concrete implementation of Solid
9 stars 3 forks source link

Question about access modes #5

Closed michielbdejong closed 5 years ago

michielbdejong commented 5 years ago

Hi!

https://github.com/solid/solid-architecture/blob/master/server/request-flow.md#step-2-parse-the-request-to-the-personal-data-store mentions required permissions are Read, Write, Append, and/or Delete, based on method, and in case of PATCH, body. I'm guessing that means GET, HEAD need Read, OPTIONS needs nothing (?), POST and PUT need Append+Write, PATCH needs Append or Append+Write, and DELETE needs Delete.

But https://github.com/solid/web-access-control-spec#modes-of-access mentions Read, Write, Append, Control.

How do these relate? I'm guessing Delete translates to Write? And shouldn't there also be http requests for which the required permissions are acl:Control? Also, when PUT or POST cause the creation of a new resource, WAC describes that as Append, and not Append+Write.

Is there a document (or should we start one) specifying in more detail how the required permissons (in terms of exact WAC modes) for a http request can be determined?

michielbdejong commented 5 years ago

Also, I'm wondering how multi-resource requests using globbing or SPARQL should work in relation to WAC and also to error/result reporting.

I'm guessing for https://github.com/solid/solid-spec/blob/master/api-rest.md#globbing-inlining-on-get such queries could always return a 200 and then in the body only include resources that matched both the query and the WAC constraints.

For https://github.com/solid/solid-spec/blob/master/api-rest.md#alternative-using-sparql I imagine it might become even trickier to report a multi-resource write operation that partially failed. Maybe this is is also something that could be addressed in the (planned) cross-server API tests?

RubenVerborgh commented 5 years ago

Is there a document (or should we start one)

We should probably start one. Here's what we need per method:

RubenVerborgh commented 5 years ago

I'm guessing for https://github.com/solid/solid-spec/blob/master/api-rest.md#globbing-inlining-on-get such queries could always return a 200 and then in the body only include resources that matched both the query and the WAC constraints.

I'm not a big fan of globbing for various reasons (notably its DDOS potential), but I follow the 200 reasoning.

For https://github.com/solid/solid-spec/blob/master/api-rest.md#alternative-using-sparql I imagine it might become even trickier to report a multi-resource write operation that partially failed.

No partial write failures should be allowed. A write either succeeds in its entirety, or it fails in its entirety.

michielbdejong commented 5 years ago

Thanks! That answers my question, closing.