Question is pretty simple, but I couldn’t find much info about it. Is there a way to know what type of POD user has? Ie NSS, CSS or ESS?
The way I am currently doing this is by checking whether POD uses WAC or ACP to distinguish between ESS vs NSS + CSS.
But this feels clumsy and unreliable.
I can share my function to check it if someone needs it.
(I’m assuming you’re asking as a developer, and want your app to detect it.) Like in regular web development, it’s probably most reliable to do feature detection to find out whether a Pod supports a feature you need, to increase the odds that your app will also work with other Solid servers that you did not explicitly think of.
Hopefully in the future we’ll get a somewhat healthy ecosystem similar to web browsers, where the different servers are mostly interoperable.
2 Likes
The x-powered-by header tells the server. AFAIK, it’s not in the spec. NSS/CSS/Trinpod support it. ESS does not.
2 Likes
If we really want to be as interoperable as possible, then we should not care about the type of server, and instead only care about the features that server advertises.
For WAC vs ACP, this is advertised by the presence of an ACP/ACR, you can see how we handle this in the Inrupt “universalAccess” APIs here: solid-client-js/getPublicAccess.ts at main · inrupt/solid-client-js · GitHub
1 Like
sure, I saw that module, but unfortunately, at the moment it doesn’t change the access of ACP pods (ie pods hosted on ESS server) because of the server bug that I wrote here about:
so, currently it is impossible to define access on ESS pods
@Greetings we are currently working to address the issue with the return value from setPublicAccess / setAgentAccess, so hopefully we’ll have an update soon. However, I’m not sure you used those APIs: Module: universalAccess — Inrupt solid-client Documentation
They’re new as of recently, looks like you’ve more explicitly used the lower level access APIs. Can you let me know if setPublicAccess / setAgentAccess work for your use case? (note: the return value is known to be potentially incorrect, so doing a getPublicAccess then, setPublicAccess then getPublicAccess should give correct results.
That is, we’re hiding the complexity of ACP/ACRs/WAC under the universalAccess API.
@ThisIsMissEm, Well in the topic which I sent to you, yes, I didn’t use the universalAccess api, because it didn’t work for me at all, but I really wanted to try and set access for ESS pods, so I tried to use other options available.
I have tried to do it as you just explain and here are the results:
Console output
So, the access wasn’t updated
But if we examine what happens in the resource’s acr:
So, if we check resource’s internal_acp.acr.graphs.default
we will see that policies and matchers are actually created and attached to the resource
The problem is that the “main” acr graph in this case:
" https://pod.inrupt.com/podsptester/toTest/?ext=acr "
doesn’t have these policies in it’s http://www.w3.org/ns/solid/acp#apply
main acr
And because polices are not listed there, they don’t actually take effect on the resource, so even though I set read, append and write to true, this file is still restricted to the general public.
After examining the code of universalAccess module, I can deduce that this is exactly the problem, because what the code in this module does to check access, is it checks if there are any policies in that “apply” part, and if there aren’t any, it returns all false.
Now, the first thought that comes in mind is that maybe in the code there isn’t any part that actually adds these policies to that “apply” part, but I think there is, the problem is that when that “apply” part is changed, changes are not recorded on the server.
This is exactly why I tried to change that file using more specific libraries, but the result is the same, that “apply” file stays unchanged.
Thus I deduce that the problem isn’t with the universal access module, but with the server, as for some reason it doesn’t allow changes to this “apply” part.
@Greetings huh, okay — thanks for the valuable information, I’ve let the team know, and hopefully we can figure out what’s going wrong and get a fix out soon.
2 Likes