-
Notifications
You must be signed in to change notification settings - Fork 44
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
defaultAccessContainer
Link header
#531
Comments
This was referenced Jun 6, 2023
I have a screencast of a demo of how the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This proposal solves the 2n+1 request cost problem for finding the effective ACL of a resource, reducing it down to a max of 2, while being fully compatible with the current spec. I have implemented this in Solid-Control Pr25 and have built a crawler script in SolidCtrl App repo.
The idea is simple: A server can add a
defaultAccessContainer
link to a resource, pointing to the effective ACL container, which will point using theacl
link to the effective acl. This is similar to the proposal in #325, which pointed directly to the effective acl. The problem with that proposal became apparent implementing a client. Fetching the direct acl for a resource makes it difficult for later requests on subresources of the default container to search their own cache for a potential default ACL candidate.Short description
We want a client to make as few requests as possible. So if it is crawling a Linked Data Event Stream or blogs on a server, it should, ideally once it has found the default ACL for one resource, be able to guess that all the other resources located in that container or subcontainers can be accessed using the same authentication mechanism. Meaning that if the LDES stream is 100 resources it would only need to make
R1
and receive a 401 with link to the default ACL dir using link type "defaultAccessContainer" to the../../
which resolves toCd
Cd
which points to ACLAr
Ar
R1
with signed header successfullyso the total number of requests would be 100+3
The direct link to the ACL reduces that by 1 to 100+2,
but it means that a client cache that presumably is following links around the web does not have information in its DB going directly from the container with the effective acl to the acl. That means that basic caches cannot be used, but one needs to enhance those with information about incoming links.
(Note: I have been thinking this through in this document The Cache)
Detailed description
This returns a response containing an
acl
link to the resource that currently does not exist but that the client can edit to create a specialised access control rule for that resource.defaultAccessContainer
link to the container that contains an existing acl with a default rule.Seeing the
defaultAccessControl
link, the client follows that link with a HEAD to find the effectiveacl
link.From that, the client can find the
acl
rulesWith that information, the client can then authenticate with a signed request using HTTP-Sig in this case
If a client wants to make a request later to
/ldes/defaultCF/2023/06/06/00_08
, the client can search through the local cache hierarchy all the way down to/ldes/defaultCF/
following reverseldp:contains
links or just the directory structure, and from there find the link to the effective acl, that will also be in the cache due to the interaction above. That can be done very efficiently as it requires no internet communication. (see also #528 ), allowing the client to sign the next request immediately.The text was updated successfully, but these errors were encountered: