Acl file is not there when creating new resource

When I create a new dataset, it seems like it is not creating .acl files on my local community server for those datasets or directory. Do I need to create them in another call? When I use the https://solidcommunity.net/ it seems like the acl files are create when adding a dataset. Is this configurable behaviour on the solid community server when I run it locally?

There is no requirement that every resource have a .acl file. Because of the inheritance of .acls, a resource is automatically controlled by the .acl of the container it is in, or if that container doesn’t have a .acl the container above that, etc. There must be at least one .acl at the root of the pod, but other than that, it is entirely dependent on how the user wants to organize their pod. It would be quite wrong for an app to automatically create a .acl resource for every file unless there was a specific reason.

3 Likes

Ok, thanks @jeffz for the clear answer!
I wanted to create a new authorization for an agent via
access.setAgentAccess
but when I call it, I get:


Because the acl doesn’t exist I think and in the code the first steps are (@inrupt\solid-client\dist\access\universal_v1.mjs):

async function setAgentAccess(resourceUrl, webId, access, options = internal_defaultFetchOptions) {
    const resourceInfo = await getResourceInfoWithAcr(resourceUrl, options);
    if (hasAccessibleAcr(resourceInfo)) {
        const acpData = await internal_getPoliciesAndRules(resourceInfo, options);
        const updatedResource = internal_setAgentAccess(resourceInfo, acpData, webId, access);
        if (updatedResource) {
            try {
                await saveAcrFor(updatedResource, options);
                return await getAgentAccess(resourceUrl, webId, options);
            }
            catch (e) {
                return null;
            }
        }
        return null;
    }
    if (hasAccessibleAcl(resourceInfo)) {
        if (access.controlRead != access.controlWrite) {
            throw new Error(`When setting access for a Resource in a Pod implementing Web Access Control (i.e. [${getSourceIri(resourceInfo)}]), ` + "`controlRead` and `controlWrite` should have the same value.");
        }
        const wacAccess = access;
        await setAgentResourceAccess(resourceInfo, webId, wacAccess, options);
        return await getAgentAccess$1(resourceInfo, webId, options);
    }
    return null;
}

So it looks like it fails on the getResourceInfoWithAcr and doesn’t recover to do some acl stuff.

That might either mean that the current user doesn’t have permission to view the given resource, or that your app isn’t listed as a “trustedApp”, although I’m not sure if CSS implements the latter. What server are you running this against, is the user that’s logged in also the one who’s Pod this is, and is there a http://www.w3.org/ns/auth/acl#trustedApp statement in that user’s profile (like e.g. in this one - search for trustedApp)? That might help narrow down the issue.

1 Like

I had some similar trouble setting the agent access for a new resource but found a great solution in the final code snippet found at [SOLVED] Solid-Client create ACL for container makes agent lose control - #3 by Vincent, you might find it useful too

2 Likes

Thanks Dylan, that worked!

1 Like