Using acl files to define access rights

I am working on a app where I want to share resources with other people. For this, I created a new folder which
is to contain my shared triples in /private/data. I managed to create an .acl file on /private/data/.acl and grant myself and my app, read, write and control access to the data folder and .acl file. When following the URL to the acl I can see that my permissions are there, yet I find myself unable to create new files in the private/data folder. I have tried adding the permission to the .acl file like this: /private/data/object1, but this does not seem to work and keep getting my access denied.

Does any of you have an idea what I am doing wrong?

1 Like

Hello,

Make sure your ACL looks like this:

@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix per: <./>.
@prefix c: </profile/card#>.

:ControlReadWrite
    a n0:Authorization;
    n0:accessTo per:;
    n0:agent c:me;
    n0:default per:;
    n0:mode n0:Control, n0:Read, n0:Write;
    n0:origin <https://the.app>.
:Read a n0:Authorization; n0:accessTo per:; n0:default per:; n0:mode n0:Read.

Both you and your app should be present in the same n0:Authorization object.

Also check that your app does not have any other global privilege in your profile:

...
    n1:trustedApp [ n1:origin <https://the.app> ];
...
2 Likes

Thank you so much, it works now :slight_smile:

Could it have been my reference to the container?

I used @prefix data: <private/data/> where your example only uses <./>

I also placed the orgin in a separate subject.

1 Like

Yes.
your reference to the container must either be relative to the pod, the folder or with full url.
You should have used :slight_smile :slight_smile:
@prefix data: </private/data/> or <./> or <yourPod/private/data/>

It is recommended to use <./> to be able to copy/move your folder with acl.

1 Like

So I got it working this morning, trying to create automatic with the following code, now I do not have the rights to create a document which I was able to create yesterday…

I use the TripleDoc module

¬†const¬†dataFolder¬†=¬†await¬†createDocument(storage¬†+¬†‚Äėprivate/data/.acl‚Äô)
    const dataFolderACL = dataFolder.addSubject();
    dataFolderACL.addRef(rdf.type, acl.Authorization)
¬†¬†¬†¬†dataFolderACL.addRef(acl.accessTo,¬†‚Äú./‚ÄĚ)¬†¬†¬†¬†
¬†¬†¬†¬†dataFolderACL.addRef(acl.agent,¬†‚Äúhttps://aardappel.solid.community/profile/card#me‚ÄĚ)
    dataFolderACL.addRef(acl.default__workaround,"./")
    dataFolderACL.addRef(acl.mode, acl.Read);
    dataFolderACL.addRef(acl.mode, acl.Write);
    dataFolderACL.addRef(acl.mode, acl.Control);
¬†¬†¬†¬†dataFolderACL.addRef(acl.origin,¬†‚Äúhttps://localhost:3000‚ÄĚ);
    dataFolder.save([dataFolderACL])

Any idea why thing are going wrong? I added myself to the parent folder…

1 Like

Does your user have Control access of /private/data? And does your app have Control access in the trustedApps listing? Do you see any error in your browser console?

Also note that you cannot assume that .acl will be the location of the ACL file for the Container. Unfortunately, the method of ACL discovery isn’t yet set in stone, and so the Tripledoc API below is still experimental (and hence not listed in the documentation), but you’d do it something like this:

const container = await fetchDocument(storage + 'private/data');
const containerAclRef = container.getAclRef();
const dataFolder = createDocument(containerAclRef);
// etc

(Also note that createDocument is not asynchronous and hence does not need to be awaited - it will only actually be created once you call .save().)

Other than that your code looks fine to me, at first sight.

1 Like

when appying my own part I get the same error as with getting the AclRef.

403 (All Required Access Modes Not Granted)

I have my app added as origin in /private/.acl

acl:origin http://localhost:3000;

It is also added to my trusted apps:

n1:trustedApp
[ n1:mode n1:Append, n1:Read, n1:Write; n1:origin http://localhost:3000 ];

1 Like

Your trustedApp in your profile should not assign any modes, if it does, they will invalidate the modes in the .acl and will not apply. Basically you tell the .acl to give Control, but then in the trustedApp you have said, don’t give it Control. So remove the mode statement from your profile. I am not sure this interaction between the profile trustedApp and the .acl origin statement is in the spec anywhere or if it will remain as is, but for now, that’s how it appears to work.

1 Like

It appears you may be right.
I have removed the modes in the trusted app, but now nothing has access to anything trough the app I made.
I get an error ‚Äú403, Origin unauthorized‚ÄĚ.
I added the origin to some of the local files, but this does not work and keep getting the 403, origin unautorized.
any ideas?

Edit: I heart there may be a bug in the acl authorization parts, can this be true?