I’ve encountered an error trying to get the permission linked to a resource after its updating on a Pod.
This is the scenario:
I ve initialized a Pod creating some folders and assigning full access to them to an user1 (and also explicit for the admin - just to stay safe).
I ve initialized those folders/Container by uploading some file and assigning full access to them to the user1 (and also explicit for the admin - just to stay secure).
i ve checked that the permission was assigned correctly. NOTE: to check i ve used the logged session of the admin of POD.
Till now all work fine.
Then, i made some operations such as retrieve some of these file, and still all work fine. NOTE: those operations was made by logged session of the user1, so the access previously assigned to him work fine.
Now, what i m trying to do is to add as “user1” other files (so using the FULL access policies set above), but different (file) from those updated as admin during the initialization of the scenario (in the sense that those new file should not have previously setted access or other).
The upload work fine, but if I try to set the access for these new file as user1 (which have FULL access to do this), this return me:
FetchError: Fetching the metadata of the Resource at [https://pod.inrupt.com/***********/Or
der-i1ir2osnb.json] failed: [403] [Forbidden].
Furthermore, This error appen also when i want to check the permission or if i want to delete this file, still using user1 logged session.
So, i ve tried to check manually, as admin, the access for these file (previously uploaded as user1) for the user1 webID, and return me an All-False access. How this could be possible considering that the file were uploaded by the user with full-access?
RECAP: Seems that i have to insert file i need as admin, set the access for the users i want, and then users can operate through these access. But this solution is not welcome.
It shall be nice to make the title clear you are on an ESS server.
ESS used ACP. not ACL to manage control access. Help may not come from the same people.
I know that ESS uses ACP, but i m using the universal access mechanism, so it work till i was explained in the post.
if Solid tells us that when we set access for a Resource for a specified user (webID) then this is not inherited by its internal resources (in case of Container/Folder), How could be possible to use these access modes to insert-delete-update new files added by the user-granted ?
i ve tried also to use a acp specifc mechanism to control this, but still i m not able to control a file after its uploaded on pod without previous access modes setted for that file (so , simply a new file never been present on the pod )
Hi @vincenzo-dip8 -
I think for what you are trying to do, you would need to also set member policies for the container (these policies would propagate down to all the resources within the container - so, be careful) for which you would need to use the ACP apis instead of the universal.
So,
Let’s say we have the container https://pod.example.com/docsteam/getting-started/readingList/
Let’s say we give user1 using universal access API {"read":true, "write":true} to the container.
a. Then, as you noticed, user1 can write user1_readingList to that container but cannot read the user1_readingList.
b. That’s because with the above access on the container, you can only “read” the container as a resource, not look at its members (i.e., resources in the container).
As you mentioned, you could then have the owner (in my example) docsteam intervene and give read access to the new resource user1_readingList. However, you would prefer that user1 have the access for all content within that container without that intervention.
To do so, you can specify member policy for the container https://pod.inrupt.com/docsteam/getting-started/readingList/ . As mentioned, be careful because member policies will be inherited, by default, by all the resources inside the container.
You can (it’s not pretty - I’m not a JS developer and relatively new to Solid, so apologies beforehand for the code):
Create a rule to match your agent user1 and save to a SolidDataset that contains your custom ACP rules.
// Where you will save your custom rules and policies
const MY_ACP_SOLID_DATASET = `https://pod.example.com/docsteam/acp/myrulesandpolicies`;
// If you already don't have a SolidDataset at MY_ACP_SOLID_DATASET URL -- create a new one locally so that you can save later.
// If you already have a SolidDataset at MY_ACP_SOLID_DATASET URL, do a get instead of a create.
let myRulesAndPoliciesSolidDataset = createSolidDataset();
// 2. Initialize your new Rules.
let agentRule = acp_v3.createRule(`${MY_ACP_SOLID_DATASET}#agent-match-rule`);
// 3. For the rules, specify the Agent to match.
agentRule = acp_v3.addAgent(agentRule, "https://pod.example.com/user1/profile/card#me");
// 4. Add your new rules to the SolidDataset.
myRulesAndPoliciesSolidDataset = acp_v3.setRule(myRulesAndPoliciesSolidDataset, agentRule);
// 5. Save the SolidDataset.
await saveSolidDatasetAt(
MY_ACP_SOLID_DATASET,
myRulesAndPoliciesSolidDataset,
{ fetch: fetch } // fetch from the authenticated session
);
Create and save a policy that uses the previous rule to grant read access to user1
myRulesAndPoliciesSolidDataset = await getSolidDataset(
MY_ACP_SOLID_DATASET,
{ fetch: fetch } // fetch from the authenticated session
);
// 2. Initialize your new Policies.
let user1MembersPolicy = acp_v3.createPolicy(`${MY_ACP_SOLID_DATASET}#user1-memberspolicy`);
// 3. Add the rules from previous examples as allOf() or anyOf() expressions to the Policies.
user1MembersPolicy = acp_v3.addAllOfRuleUrl(
user1MembersPolicy,
`${MY_ACP_SOLID_DATASET}#agent-match-rule`
);
// 4. Specify the access modes for the policies.
user1MembersPolicy = acp_v3.setAllowModes(
user1MembersPolicy,
{ read: true },
);
// 5. Add your new Policies to the SolidDataset.
myRulesAndPoliciesSolidDataset = acp_v3.setPolicy(myRulesAndPoliciesSolidDataset, user1MembersPolicy);
// 6. Save the SolidDataset with the new Policy.
await saveSolidDatasetAt(
MY_ACP_SOLID_DATASET,
myRulesAndPoliciesSolidDataset,
{ fetch: fetch } // fetch from the authenticated session
);
Then, just add that policy as a MemberPolicy to your container
// Get the Container with its ACR
const resourceWithAcr = await acp_v3.getSolidDatasetWithAcr(
"https://pod.example.com/docsteam/getting-started/readingList/",
{ fetch: fetch } // fetch from the authenticated session
);
// Add the newly created policy as a Member Policy for the Container
let changedResourceWithAcr = acp_v3.addMemberPolicyUrl(
resourceWithAcr,
`${MY_ACP_SOLID_DATASET}#user1-memberspolicy`
);
const updatedResourceWithAcr = await acp_v3.saveAcrFor(
changedResourceWithAcr,
{ fetch: fetch } // fetch from the authenticated session
);
Once you have saved the memberPolicy successfully, user1 should be able to read any Resource (even ones that they didn’t upload) within the Container unless you specifically modify a particular access for a Resource. Hope this helps.