.acl format for authorising new apps



I am trying to authorise a file manager to read and write in my Solid POD running on version 5.0.0. However, i am getting unauthorised access error when i use the following code in the root .acl file. Please correct me if i did any mistakes.

a acl:Authorization;
acl:agent < https://student1.solid.open.ac.uk/profile/card#me >;
acl:accessTo </>;
acl:default </>;
< https://otto-aa.github.io/>;
acl:Read, acl:Write, acl:Control.


I think you need to remove the trailing slash in https://otto-aa.github.io/, ie make it https://otto-aa.github.io .

Does that work?


@megoth Arne - could you clarify the difference between this kind of per-resource authorization of apps and the use of acl:trustedApp in a profile? Do I understand correctly that the acl:trustedApp in the profile gives the app the specified rights in all folders? If there is a more specific .acl somewhere pointing to a specific folder, does that one take precedence for that folder over the generic profile declaration?


The way I suggest my users to do this in the filemanager is to go to my-pod.com/profile/card#me, click on the “A” in the top, and add it via this interface.

I personally believe, that such a critical feature should be easier to find (ie not going to some page, where you need to hover over the top side and click on a random “A”), but I find it easy to use :+1:


Beware there is a bug when you use more then one trusted app with A pane : the only retained permission is read for the added ones.


Nope it didnt work.


Thanks for this. But still it gives the same error. It will be interesting to see in which .acl file this particular interface adds authorization to the apps. Because the root .acl doesnt change after authorizing an app in it.


I’ll give it a go, but take it with a grain of salt, as I’m surprised by the intricacies of of WAC sometimes :smile_cat:

Yes, it gives the trusted app access to the whole pod, for all modes you grant it and that you have yourself. So a trusted origin with Read access can traverse your pod and read all of your data.

Another case (which is very hypothetical, but might help to give more insight): lets say you grant Control access to an app (which you probably wouldn’t) and your WebID for some reason don’t have Control access to a resource in your pod, the app will also not have Control access to that resource.

The trustedApp triples are evaluated independent of the ACL files (this is why they reside in your profile, not in specific ACL files), so precedence is not a factor in this case.

Again, it might be that I’ve misunderstood something in the spec here, so very much open to counter-arguments :smile_cat: