Programmatically adjust ACL

I also want to note, that my implementation is just one way of doing this. It parses the whole acl file into an object, modifies it, and parses it back. Another way would be to use a library to directly manipulate the turtle (e.g. with SPARQL statements)

Hey @A_A I had some time to try your lib and it is exactly what I was looking for. Thank you very much.

I am encountering just a small problem, perhaps you have an idea:

Couldn’t retrieve the acl location from the link header

This occurs, if I try to add an ACL to a container and there is now ACL except the root acl. If at least one of the parent containers has an ACL everything works fine. But the root ACL cannot be discovered somehow. Might as well be a bug in NSS, not sure.

With curl I can get a link to the ACL file from a Pod root:

▶ curl -s -I | grep Link:
Link: <.acl>; rel="acl", <.meta>; rel="describedBy", <>; rel="type"

But in the browser dev tools it is actually not to be found in the response of the OPTIONS request to the Pod root:

Link: <>; rel="service", <>; rel=""

Any ideas?


Apparently node-solid-server only sets the link header for GET but not for OPTIONS requests on the root. Here’s a simple script to reproduce it from the browser console when logged in to your pod:

fetch('/', { method: 'GET' }).then(res => console.log(res.headers.get('link')))
// <.acl>; rel="acl", <.meta>; rel="describedBy", <>; rel="type"
fetch('/', { method: 'OPTIONS' }).then(res => console.log(res.headers.get('link')))
// <>; rel="service", <>; rel=""

So I believe that it’s an issue of node-solid-server not adding rel="acl" to the link header.

EDIT: For HEAD it works fine. I’m not that familiar with the difference between HEAD and OPTIONS, so probably that should be used instead. If you know more about it just let me know and I’ll change it


I think a HEAD request would be correct as stated in Discovery of Auxiliary Resources

To discover the auxiliary resources directly associated with a given Solid resource, a Solid client MUST issue a HEAD or GET request to the target resource URL and inspect the Link headers in the response.

1 Like

I’ve updated it to use HEAD, can you try it with this version?


Awesome, it’s working :+1: Thanks a lot

1 Like

Hi @A_A sorry to bother you again. Your library has no capability to set a acl:default, or am I missing something?

You can use addDefaultRule(...) instead of addRule(...) to set the default.

Basically you can use everything defined in this map and all methods defined in this class. So if you don’t find a functionality in the documentation you can take a look there (and open a PR to add it to the documentation :))

1 Like

Thanks a lot, sorry I should not have missed that!

Hi @A_A, those libraries are great, as is your pod explorer.
is there any change you can add support for the origin predicate? this would allow trusted apps.

@A_A the issue is that if I create an ACL for a file inheriting (defaulting to) an origin predicate, the subject still points to the default location).

For example, this is what happens to the acl for after I load the default, amend it, and save it:

@prefix foaf: <>.

<#trusted-apps> a acl:Authorization;
    acl:agent </profile/card#me>;
    acl:accessTo <./foo.txt>;
    acl:mode acl:Control, acl:Read, acl:Write.
<> acl:origin <https://localhost>.
<#ControlReadWrite> a acl:Authorization;
    acl:agent </profile/card#me>, <>;
    acl:accessTo <./foo.txt>;
    acl:mode acl:Control, acl:Read, acl:Write.
<#Read-0> a acl:Authorization;
    acl:agent <>;
    acl:accessTo <./foo.txt>;
    acl:mode acl:Read.

You can see that the origin predicate still points to the parent.

I tried to bodge it by changing the structure just before saving it, but it does not have a setter, so I was wondering if you were inclined to add origin support.

You can take a look at the new inrupt lib too
Seems quite easy to deal with Acl

Looks nice indeed, but seems not to be able to add an origin to a permission, yet.

Doesn’t the new Inrupt Client Library include support for adjusting the ACL?
Or are its abilities not advanced enough? (haven’t gotten a chance to look at it closely yet.)

That’s what @Smag0 and I referred to :wink:

1 Like

Oh wow, completely missed that.
Sorry for the remark then.

No problem, nice to see you

That is correct, it does not currently support handling origins. Also note that it’s still in Beta, which is especially relevant when dealing with security-related code such as ACLs.

(I work on solid-client.)


With this library you can add permissions to origins:

However you can’t add ‘Append’ permissions yet, it is yet to be implemented

1 Like

I’ve replied in the github issue (here).
TL;DR: It’s not maintained, but feel free to open a PR. I’ve explained what I think would be needed to change