-
Notifications
You must be signed in to change notification settings - Fork 19
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
Exposure of metadata link headers to all clients #36
Comments
I think server should only insert links to a metadata resource in the response if credentials from the requests would allow read (or write if doesn't it doesn't exist yet) access to that metadata resource. I can't imagine case where client would need to know those links if it doesn't have access to them. |
I think that depends on how a client is supposed to request access to ressources ; does it need the link to initiate a "can this app do X" request? |
Not sure I understood what your meant @ericprud To discover links to metadata resources client has to do GET / HEAD request to the resource itself. Server check acl for that resource and based on that it could decide to include or not to include links. Not sure if we need to handle cases where app A with subset of user's access rights makes requests but app B with different (possibly broader) access rights would handle interactions with metadata resources. |
I was just thinking about the mechanics of how the client finds out that there are resources that it can't access. There's a perennial tension between 401 and 403. Maybe they were originally conceived as: It might seem conservative to say we won't leak things by not mentioning their existence, but we're (mostly) talking about resources that the client knows exist and may have a guess about how to discover (e.g. append ".acl" to the Location that just came back from a 200). A more nuanced approach might be to include Links to all reserved resources and have some configuration that controls whether to leak server-managed resources. |
[With my haven't-read-the-draft-proposal-hat-on] Do (or can?) metadata resources have different authorization policies than the resource they are about? If resource and resource metadata have the same policy, it is acceptable to expose the relation, otherwise play it by the policy. This is related to a wider discussion on privacy in Solid.. may want to keep this in mind: solid/specification#14 , solid/specification#116 , solid/specification#125 , solid/specification#41 (and I'm sure there are more issues with similar implications and considerations). |
@csarven Yes - they can be different. Each metadata type is subject to different authorization criteria, which is specified in the definition of each individual type. For example, a server managed metadata resource can only be written by the server. Clients with read and write permissions on the resource the metadata is directly associated with can still only read the metadata resource. |
From a client-side implementation point of view, it is a huge pain having to query every single resource to find the location of its linked data. Consider recursively copying a container from a server with linked-data-location-policy-A and another with policy B. We can't copy the .acl first because we don't know where we should copy it to until there is a resource to query about the location of the new .acl. So we copy the resource and leave it unprotected while we then query that new location of the resource to see where we should put the .acl. It would be so much easier if there were a server-wide query that gave the location pattern of linked resources so that we didn't need to query each resource. As for not divulging the source of protected linked resources - servers will need randomizing ways of generating the links because something like what NSS does is trivial to suss out (just add .acl). |
As a general rule, should all clients see links to metadata resources associated with a given document, or should this be something defined for each individual type of metadata?
The text was updated successfully, but these errors were encountered: