-
Notifications
You must be signed in to change notification settings - Fork 47
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
Current Container Listing mechanism does not support hidden resource use case #626
Comments
I agree this can be useful. Indeed I found a use case in the Storing an Apps Public Key use case. But this raises an important question: how can a client know that if it were to authenticate as X then it would be able to see more? This problem is similar to the one raised in issue 45: No way to find out if user is authorized to write to a container and is also described in Client Authentication Discovery. |
I think you may be missing the point of hidden resources. The client is not supposed to know that if it were to authenticate it would be able to see more. And shouldn't. As in, that's the main value of the feature. |
As pointed out I have a use case for hidden resource in Storing an Apps Public Key and I can see other uses for it too, in cases of strong privacy protection. But this does not mean that there are no use cases where it is useful to see resources that are protected. For example
What is actually needed is a way to state that links to a certain hidden resources should be hidden when one wishes that to be the case, and to be able to state that links to hidden resources are visible when one wants that to be the case. So I think actually we need a vocabulary for describing views on resources, which could be part of acl. That is a new feature since:
If we don't document this there is no reason some servers will go one way and others the other, and clients won't have any way of knowing what the server will do ahead of time. |
I agree, there's definitely a need to explicitly state the two different intentions - 1) this resource is hidden (and so doesn't show up on lists, and accessing it yields a 404), and 2) this resource is not hidden but locked (and so yields a 401). |
@bblfish +1 this is a new feature, and not a bug. I would prefer this issue to be phrased in amore neutral way. The opening premise:
That's not the case is it. The argument is that the names of files may be leaked, if they are put in a public container. Of course there is another solution: dont put the names of those in a public container.
I would also like to see this rephrased in more neutral language, I think it's too strong.
Also what are all the relevant implementations? Does this not apply to all LDP next and upcoming Solid implementations? Could we try to investigate all the systems that might need to make changes?
Do you have a pointer to this? From what @sandhawke said in the meeting I remember, containers should either list all resources in them or none. I may have misheard there. It seems like this proposal actually is an architectural change. Perhaps there's implications as to the RESTfulness etc. that may need a lot of consideration. |
@dmitrizagidulin Is it just that the unauthenticated user or not-connected user can see a list of all the resources in the container, or that they can see the listed items themselves? Either way, it's not acceptable, I'm just trying to understand. It seems very important to support the ability to set a general permission on a container (public, for example), but allow an arbitrary number of overrides on the items in the container, including other containers, etc. For example, let's say you have a blog post in an unfinished state and you just want to save it and come back to it tomorrow. So, you want it to be private for the time being until you're ready to publish it. Anyway, there are dozens of use cases... |
Just throwing this out there.. Thinking along the lines of the following behaviour:
The "resources to ignore/hide from containment listing" can be managed by applications. Server can look up the ignore/hide index when it needs to generate the containment statements. Being on the ignore/hide list can/may impose additional semantics, behaviour, access on resources. https://solidproject.org/ED/protocol (as of this writing) does not specify the visibility of auxiliary resources in containment statements. Some server implementations do omit auxiliary resources in containment statements. This behaviour is equivalent to the declarative approach of using an ignore list. The default behaviour could be to hide auxiliary resources from containment - whether or not mentioned in the ignore/hide index. Furthermore, while it'd be an implementation detail for the servers to omit the visibility of certain resources (at least from a container description) that it deems it should, e.g., |
The current mechanism to list resources in a Solid container does not support an important social media use case.
Say I'm implementing a social blog service (like LiveJournal or Facebook) that allows me to specify access control on each post: public, private (only I can see and read those posts), and friends-only.
Using the current Solid spec and implementation, I cannot simply put my Posts as resources in a
/blog/
Container, and set their corresponding ACL files. This is because when an un-authenticated user (or an authenticated user who is not on my Friends list) does a List Resources request on the/blog/
container, they will see all of the posts listed on my blog, even private or friends-only ones.In other words, as a non-friend, I do
GET dmitri.databox.me/blog/
, I will see that it contains:public post 1
(which means I have read access to it, no problem)private post 2
(I can see it on the list, but get a 401 / access denied when I try to request it)friends-only post 3
(again, I can see it on the list but get access denied)This is completely un-usable, in terms of being able to implement private/hidden resources in the context of a social media app.
After a discussion with @deiu, @sandhawke and @nicola, the proposal is to:
The text was updated successfully, but these errors were encountered: