You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The spec currently speaks about accessTo in the plural form, suggesting that multiple accessTo's can be used in the same document or even authorization block. Contrary to that, I've heard in another issue, that only one accessTo is expect per acl document. I think it would be good to clarify this.
The acl:accessTo predicate specifies which resources you're giving access to, using their exact URLs as the objects.
The text was updated successfully, but these errors were encountered:
Yes, multiple acl:accessTo statements about the same authorisation node are possible, but what matters is that you check whether or not the authorisation node gives access to the resource from which you followed the link. So if you look at /folder/ and see a link header that points you to /.one-big-acl-doc then you need to look only at authorisation nodes in there that have #node acl:accessTo </folder/>, and not to any other authorisation nodes that may exist in that /.one-big-acl-doc
However, it is common in server implementations (NSS and IPS) to use /folder/.acl and not /.one-big-acl-doc, so then this situation doesn't occur - all authorisation nodes will have either #node acl:accessTo </folder/> or #node acl:default </folder/>, or just be irrelevant / ignored
Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ .
See See #authorization-conformance and #authorization-matching .
The spec currently speaks about accessTo in the plural form, suggesting that multiple accessTo's can be used in the same document or even authorization block. Contrary to that, I've heard in another issue, that only one accessTo is expect per acl document. I think it would be good to clarify this.
The text was updated successfully, but these errors were encountered: