-
Notifications
You must be signed in to change notification settings - Fork 25
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
Precise definition of acl:default #63
Comments
No, that's not how In the first case, look for
|
Thanks for coming back to this question. I think I am understanding what you are saying, but I'm not sure how it answers my question. I'll try to explain my question with a simple example. Here is the example for acl:default from the wac-spec. Only the last line is changed:
I've changed the value of acl:default from ".../docs" to ".../docs/first.ttl". Does this change the behavior of it? Or is this value redundant? |
@Otto-AA asks an excellent question here. I have had that same question, myself. I also have another question that touches on Assume there exist the following four resources:
The There is also a
There is no ACL resource for If the user |
@acoburn I believe it would use /docs/.acl in your case because this is the first acl file with acl:default specified, hence providing the first permissions which can be inherited. From the ACL Inheritance Algorithm:
|
@Otto-AA yes, that is also my understanding (and that is how I have implemented the WAC algorithm myself), but it is worth noting that the definition in the algorithm conflicts in this regard with what is stated in the ACL namespace:
That is, when looking up the containment hierarchy, does one stop at the first "container with an existing ACL file [with] permissions to inherit" (as per the algorithm described here) or at the first container resource "which has an ACL file" (as per the vocabulary). |
Here you're mixing up the target URL of the request and the context URL of the ACL doc. So you should always keep track of three resources, and not confuse them:
All
that will be rejected. Only one ACL doc, the closest one up the tree, is looked at - in this case /docs/photos/.acl and not /docs/.acl |
In that case, what is the use of |
@michielbdejong in the ACL Inheritance Algorithm Example, it appears clear that |
I think That's how you interpret the ACL doc once you've found it. The word inheritance is confusing there, and so is the word default. And then to find the ACL doc that applies, you just walk up the tree and stop when you find one. So there inheritance is also confusing, because in biology you inherit things from all your ancestors up to the root, and in WAC you don't. EDIT: Sorry, I wrote |
I agree with @acoburn that the current form of the WAC-spec clearly states, that it looks for the next parent with an From the example in the spec:
|
Is this specified somewhere? As far as I've seen, the specification doesn't mention what the object of acl:default should be. |
@Otto-AA you're right, the only phrase that describes not looking at the presence of acl:default statements is "If the document's container has no ACL resource of its own, the search continues upstream". My reason for creating #70 is that it's how the current servers work in practice, so the 0.8 spec should be corrected to describe that. We can then have a discussion in solid/specification#55 about whether the current Solid server deployments should switch to the different behaviour that is described in the current spec text, or maybe even to yet other behaviour. |
This is not correct. There are implementations in the wild right now that follow the algorithm as described in the specification text. It does not follow that the specification text should be changed because one particular implementation does not follow those rules. (And I think it should be verified that, in fact, NSS does not conform, because these lines suggest that it does). |
All the code I have ever written follows the spec. Is "default" too short when it should be something lke "defaultForThingsWhich DoNotHaveACloserACLFileAndAreBelowThis" ? maybe a bit .. Make contentsDefault or something... but it is definitely a default, as it provides a fallback ACL for anything until that thing has something of its own or something closer. |
While @timbl's answer settles the question of whether it matters, I'd still like to see a precise definition of how it matters. It seemed meaningful to repurpose this issue in that sense. Specifically, I'd like a definition of the set of resources affected by the default. Also, @acoburn's question was specifically about the value (triple object) of the triple. How does it affect behavior? What kind of values are allowed in a given folder? Should they always be subfolders of the current folder? Etc. |
Ah wait, this is just a duplicate of solid/specification#55 then. Let's continue over there. |
The spec states "[...] if an Authorization contains acl:default, it will be applied by default to any resource in that container". Does that mean that value after acl:default doesn't make any difference?
For instance should following statements be treated as equivalent?
The text was updated successfully, but these errors were encountered: