this post was edited to describe the issue in a more clear way
Hey everyone, not sure where I should do this (plus not sure if it actually is an error, or I did something wrong)
Here is the thing, reading the description of setPublicAccess function from:
https://docs.inrupt.com/developer-tools/api/javascript/solid-client/modules/access_universal.html#setpublicaccess
it says:
Additionally, two caveats apply to users with a Pod server that uses WAC:
- If the Resource did not have an ACL yet, a new one will be initialised. This means that changes to the ACL of a parent Container can no longer affect access people have to this Resource, although existing access will be preserved.
and I seems like it actually does not initialize a new ACL.
First scenario:
- I would create a container at “https://inrtester2.inrupt.net/test/”
- then after it is created I would call the setPublicAccess function to try and set ACL on this container
- I would assign the return of the function to upd variable and then console log it, this is done because the return of the function is the access that was set or null, therefore if we get an object with defined access in the console, that would indicate that the function has actually created the ACL for the resource but judging from the console outcome it did not happen. (because the container was just created, it is “fresh” and doesn’t have ACL set, therefore from the description of the setPublicAccess function it should have created it)
This is the code for the scenario described above:
Code of the scenario 1
And this is the console outcome:
console outcome of scenario 1
Second scenario:
For the purity of the experiment I have deleted the created “https://inrtester2.inrupt.net/test/” in scenario 1 and repeated the process with slight change:
- I Create the container “https://inrtester2.inrupt.net/test/”
- (this is the change from scenario 1) I before calling setPublicAccess, I create ACL for our container manually by using WAC specific functions.
- I call setPublicAccess on the container and now it works as expected (access object is logged in console), because it was called on the resource that already has ACL existing.
code for scenario 2
console outcome of scenario 2
how ACL was set in scenario 2
P.S in the console outcome for the scenario 1 we can see the error coming from the setPublicAccess call, and it seems like the function tried to find the ACL of the resource, but couldn’t and threw 404 error
401 errors usually indicate that the user is not logged in. Are you able to perform other privileged requests (e.g. saveSolidDatasetAt) using that fetch?
yes, I am able to use saveSolidDataSetAt and that would work. As well as in my example createContainerAt, would create the container in the pod, neither of these functions would generate 401 errors.
the GET errors on the screenshot (and 401 as well) come from getSolidDatasetWithAcl call, and they would only appear if the resource doesn’t have ACL set, once it is set the consequent getSolidDatasetWithAcl calls to the same resource wouldn’t generate errors.
But the main question here is why setPublicAccess is not creating the ACL for a resource that doesn’t have one?
Actually a small update on the 401 type of errors, seems like the reason to those was due a typo in url (if you don’t add / in the end the 401 would appear, and if you do add / it doesn’t)
I apologize for the inconvenience caused, I have edited the original message and screenshots in it so that it doesn’t include these errors.
OK, the GET errors are no problem - the functions are first checking whether an ACL already exists, before creating a new one.
However, it looks to me as if your function succeeded just fine. I can see the Resource you created when not logged in, so it is publicly readable. However, you set controlRead and controlWrite to false, so presumably that’s the reason why you can’t see the ACL? What leads you to conclude that it hasn’t created it?
The reason why it actually exist is because the second time I explicitly created the ACL for it using function from WAC specific module.
To clarify a bit the code that I posted:
First scenario:
- I would create a container at “https://inrtester2.inrupt.net/test/”
- then after it is created I would call the setPublicAccess function to try and set ACL on this container
- I would assign the return of the function to upd variable and then console log it, this is done because the return of the function is the access that was set or null, therefore if we get an object with defined access in the console, that would indicate that the function has actually created the ACL for the resource but judging from the console outcome it did not happen. (because the container was just created, it is “fresh” and doesn’t have ACL set, therefore from the description of the setPublicAccess function it should have created it)
This is the code for the scenario described above:
Code of the scenario 1
And this is the console outcome:
console outcome of scenario 1
Second scenario:
For the purity of the experiment I have deleted the created “https://inrtester2.inrupt.net/test/” in scenario 1 and repeated the process with slight change:
- I Create the container “https://inrtester2.inrupt.net/test/”
- (this is the change from scenario 1) I before calling setPublicAccess, I create ACL for our container manually by using WAC specific functions.
- I call setPublicAccess on the container and now it works as expected (access object is logged in console), because it was called on the resource that already has ACL existing.
code for scenario 2
Uploading: ed7fbd49860af6819f9c69d896e0b5b7fac3a671.png…
console outcome of scenario 2
how ACL was set in scenario 2
P.S in the console outcome for the scenario 1 we can see the error coming from the setPublicAccess call, and it seems like the function tried to find the ACL of the resource, but couldn’t and threw 404 error
Ah OK, looking at that error message, that looks like a bug in solid-client that you’ll probably want to report there. For some reason, it appears to think that your Pod is governed by Access Control Resources rather than Web Access Control (because it’s calling getResourceInfoWithAcr and fetchAcr), even though inrupt.net as far as I know still uses WAC.
I’m not sure if you’re able to follow that, but if you point to this post in your bug report, hopefully the maintainers of solid-client will be able to debug further.
