Hi,
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.
<#trusted-apps>
a acl:Authorization;
acl:agent < https://student1.solid.open.ac.uk/profile/card#me >;
acl:accessTo </>;
acl:default </>;
acl:origin
< https://otto-aa.github.io/>;
acl:mode
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 
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.
https://github.com/solid/solid-panes/issues/63#issuecomment-480584501
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 
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
Hi,
I tried adding https://otto-aa.github.io to trusted app on one of my solid server setup up
And still i get the error when i try to create a new folder/file or upload a file:
Can you please let me know if i am doing any mistake here or is there any other approach to solve this.
Thanks
The problem may be the user and not the application.
By default on the nodejs server, the root acl file allow a public read permission (but only the owner can write resources).
<#public>
a acl:Authorization;
acl:agentClass foaf:Agent;
acl:accessTo </>;
acl:mode acl:Read.
@Hyuryu thanks for the replay.
Got it, but if i explicitly want to provide access to a specific application for example: https://otto-aa.github.io what would the acl file look like.
Any direction/sources to refer as how this can be achieved will be of great help.
@prefix acl: http://www.w3.org/ns/auth/acl#.
<#trustedApp>
a acl:trustedApp;
[
acl:mode acl:Append, acl:Read, acl:Write;
acl:origin <https://website-a>
],
[
acl:mode acl:Append, acl:Read, acl:Write;
acl:origin <https://website-b>
]
is this how one can give access to website and does adding this on the root level acl grant permission for the website to access the whole of the pod.
As far as I know, the trustedApp statements belong in your user profile, rather than in an ACL file. @megoth, please correct me if that’s not right. In the profile, the trustedApps apply to the entire pod. BUT remember that access needs both user and app permissions so if the app has rights to the whole pod but the user using the app does not, access will not be granted.
@jeffz you are correct 
@jeffz @megoth in that case doesn’t this acl file provide the user with complete access on the pod
# Root ACL resource for the user account
@prefix acl: http://www.w3.org/ns/auth/acl#.
@prefix foaf: http://xmlns.com/foaf/0.1/.
# The homepage is readable by the public
<#public>
a acl:Authorization;
acl:agentClass foaf:Agent;
acl:accessTo </>;
acl:mode acl:Read.
# The owner has full access to every resource in their pod.
# Other agents have no access rights,
# unless specifically authorized in other .acl resources.
<#owner>
a acl:Authorization;
acl:agent <https://ajay.uninity.com/profile/card#me>;
# Optional owner email, to be used for account recovery:
acl:agent <mailto:ajay@gmail.com>;
# Set the access to the root storage folder itself
acl:accessTo </>;
# All resources will inherit this authorization, by default
acl:default </>;
# The owner has all of the access modes allowed
acl:mode
acl:Read, acl:Write, acl:Control.
And i have added trustedApp on my card as well:
@prefix : <#>.
@prefix solid: http://www.w3.org/ns/solid/terms#.
@prefix c: https://ajay.uninity.com/profile/card#.
@prefix schem: http://schema.org/.
@prefix n0: http://xmlns.com/foaf/0.1/.
@prefix n1: http://www.w3.org/ns/auth/acl#.
@prefix ldp: http://www.w3.org/ns/ldp#.
@prefix inbox: https://ajay.uninity.comundefined//inbox/.
@prefix sp: http://www.w3.org/ns/pim/space#.
@prefix n2: https://ajay.uninity.comundefined//.
c:me
a schem:Person, n0:Person;
n1:trustedApp
[
n1:mode n1:Append, n1:Read, n1:Write;
n1:origin <https://localhost:3000>
],
[
n1:mode n1:Append, n1:Read, n1:Write;
n1:origin <https://solid.community>
];
ldp:inbox inbox:;
sp:preferencesFile <https://ajay.uninity.comundefined//settings/prefs.ttl>;
sp:storage n2:;
solid:account n2:;
solid:privateTypeIndex
\ https://ajay.uninity.comundefined//settings/privateTypeIndex.ttl;
solid:publicTypeIndex
\ https://ajay.uninity.comundefined//settings/publicTypeIndex.ttl;
n0:name “ajay”.
<> a n0:PersonalProfileDocument; n0:maker c:me; n0:primaryTopic c:me.
Even with this above settings i get the error when i try to upload files to my pod.
I am sorry if I am missing out something.
Thank you.
I’ll try breaking down the triples you have:
<#public>
a acl:Authorization;
acl:agentClass foaf:Agent;
acl:accessTo </>;
acl:mode acl:Read.
This section gives everyone (the public) READ access to the root of your Pod. This can of course be overwritten “further down”, e.g. the private folder don’t have triples for the public (i.e. a triple that has <subject> acl:agentClass foaf:Agent;).
<#owner>
a acl:Authorization;
acl:agent <https://ajay.uninity.com/profile/card#me>;
# Optional owner email, to be used for account recovery:
acl:agent <mailto:ajay@gmail.com>;
# Set the access to the root storage folder itself
acl:accessTo </>;
# All resources will inherit this authorization, by default
acl:default </>;
# The owner has all of the access modes allowed
acl:mode
acl:Read, acl:Write, acl:Control.
This gives the controller of https://ajay.uninity.com/profile/card#me READ, WRITE and CONTROL access to your Pod. There might be a bug with the authentication part of https://ajay.uninity.com/profile/card#me, which would cause the problems you’re referring to. If you have access to the server logs for ajay.uninity.com, you might verify this.
c:me
n1:trustedApp
[
n1:mode n1:Append, n1:Read, n1:Write;
n1:origin <https://localhost:3000>
],
[
n1:mode n1:Append, n1:Read, n1:Write;
n1:origin <https://solid.community>
];
This notes https://localhost:3000 and https://solid.community as trusted apps, both with APPEND, READ and WRITE access. As @jeffz mentioned, if your WebID for some reason don’t have WRITE access to a folder, the app won’t get WRITE access either.
Based on this, I cannot understand why you’re having problems with creating new folder/files or uploading files… Could be something with the authentication of https://ajay.uninity.com/profile/card#me, but I doubt that. Maybe a bug in NSS?
@megoth I get it now.
Thanks for taking the time out to explain this.
I tried a approach where i appended the acl:origin in the root acl file and it did grant me the full access for the app https://otto-aa.github.io to alter my pod contents.
I am running NSS-5.1.3 and here is my root acl file
# Root ACL resource for the user account
@prefix acl: http://www.w3.org/ns/auth/acl#.
@prefix foaf: http://xmlns.com/foaf/0.1/.
# The homepage is readable by the public
<#public>
a acl:Authorization;
acl:agentClass foaf:Agent;
acl:accessTo </>;
acl:mode acl:Read.
# The owner has full access to every resource in their pod.
# Other agents have no access rights,
# unless specifically authorized in other .acl resources.
<#owner>
a acl:Authorization;
acl:agent <https://ajaykumar.uninity.com/profile/card#me>;
# Optional owner email, to be used for account recovery:
acl:agent <mailto:ajaykumar@gmail.com>;
acl:origin <https://otto-aa.github.io>;
# Set the access to the root storage folder itself
acl:accessTo </>;
# All resources will inherit this authorization, by default
acl:default </>;
# The owner has all of the access modes allowed
acl:mode
acl:Read, acl:Write, acl:Control.
I tested this on folders inside pod like for public/private folder and a new folder and the access to the app where it can write was just given to the folder alone.
So is this considered as a work around or is this the right way.