Skip to content
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

Open
justinwb opened this issue Jan 8, 2020 · 7 comments
Open

Exposure of metadata link headers to all clients #36

justinwb opened this issue Jan 8, 2020 · 7 comments
Labels

Comments

@justinwb
Copy link
Member

justinwb commented Jan 8, 2020

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?

@elf-pavlik
Copy link
Member

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.

@ericprud
Copy link
Contributor

ericprud commented Jan 9, 2020

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?

@elf-pavlik
Copy link
Member

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.

@ericprud
Copy link
Contributor

ericprud commented Jan 15, 2020

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:
401: go pester the user for an authId with privilege to see this resource.
403: don't pester the user 'cause no one has access to this resource.
Sites that don't want to leak the existence of things use a 404 instead of a 401. Because of that, many users have adapted with the habit of looking for a login button when they get a 404.

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.

@csarven
Copy link
Member

csarven commented Jan 15, 2020

[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).

@justinwb
Copy link
Member Author

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?

@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.

@jeff-zucker
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants