Hi everyone,
I’m trying to set access to a Resource in my Pod. This is my code
async function setAccess(resourceUrl, agentOrGroupID, access, session){
var myResourceWithAcl, resourceAcl;
try {
if (isFile(resourceUrl))
myResourceWithAcl = await getFileWithAcl(resourceUrl, { fetch : session.fetch});
else if (isDataset(resourceUrl)){
//myResourceWithAcl = await getSolidDatasetWithAcl(resourceUrl, { fetch : session.fetch});
console.log("It is Dataset");
//return false; //TEMPORARY EXIT
}
else
myResourceWithAcl = await getResourceInfoWithAcl(resourceUrl, { fetch : session.fetch});
//console.log(myResourceWithAcl); //LOG #1
//console.log(getEffectiveAccess(myResourceWithAcl)); //LOG #2
if (!hasResourceAcl(myResourceWithAcl)) {
if (!hasAccessibleAcl(myResourceWithAcl)){
console.log("The current user does not have permission to change access rights to this Resource.");
return false;
}
console.log("The Resource-specific ACL does not exist");
if (!hasFallbackAcl(myResourceWithAcl)) {
console.log("The current user does not have permission to see who currently has access to this Resource.");
console.log("I'm creating a new one");
resourceAcl = createAcl(myResourceWithAcl);
}
else {
console.log("I'm creating a new one from the FallbackACl.");
resourceAcl = createAclFromFallbackAcl(myResourceWithAcl);
}
}
else
resourceAcl = getResourceAcl(myResourceWithAcl);
console.log("resourceAcl");
console.log(resourceAcl); //LOG #3
const updatedAcl = setAgentResourceAccess(
resourceAcl,
agentOrGroupID,
access
);
await saveAclFor(myResourceWithAcl, updatedAcl, { fetch : session.fetch});
return true;
} catch (error) {
console.log(error);
}
}
Hi @vincenzo-dip8, unfortunately pod.inrupt.com does not implement WAC (aka ACLs), so code that assumes that won’t work there.
What you can do, if it covers your use cases, is use the high-level API that automatically switches between WAC and ACPs as needed. If you need more fine-grained control, you’ll need to manually detect which is supported by the user’s Pod.
What i know is this:
Inrupt libraries describe 3 mechanism to control access on resources. ACP, WAC, and Universal.
I started using Universal mechanism but i found that some functions (e.g. setAccessFor) cannot be imported. I tried to import other (Universal) functions, but some cannot be see.
Those highlighted cannot be used. In visual code when i put the mouse over the function name, this highlight its declaration. With those function it just show nothing (indeed they are blue-highlighted).
Oh, even if i insert them in the code, those return me error
The other major Solid server implementation, Node Solid Server (which powers inrupt.net and solidcommunity.net ), does not provide support for ACP. Those servers use Web Access Control (WAC). WAC is not recommended for production use. For managing access to Pods on those servers, see Manage Access to Data (WAC) instead.
While for WAC:
Although Inrupt’s Enterprise Solid Server (ESS) supports Web Access Control (WAC) in compliance with the Solid specification, due to known security issues with WAC, WAC is not recommended for Production environments.
For production, Solid servers using Access Control Policy (ACP) is recommended. For managing access with ACP, see Manage Access to Data (ACP) instead.
Since i m not using ESS on Inrupt, but “base” version on broker.inrupt.pod.com Browser as Pod Space and i d like to interact with it, i opted for WAC.
What i can do? I repeat, some function to use as universal access cannot be imported in code
I say that because I used to work at Inrupt and I know that is the case
As for the import errors, you might notice from the docs that they’re not imported from @inrupt/solid-client, but from @inrupt/solid-client/access/universal". This is primarily to avoid name collisions with the other access functions, although I’d expect in time (as submodule imports become more widespread in the JS ecosystem) that all functions move to their own modules. So instead of:
import { getPublicAccess } from "@inrupt/solid-client";
do
import { getPublicAccess } from "@inrupt/solid-client/access/universal";
Alternatively, if submodule imports don’t work for you, you can import the access object directly from the top-level, although this is undocumented and thus may be removed at any time in the future:
import { access } from "@inrupt/solid-client";
// You can now call `access.getPublicAccess()`
I’m not sure what you mean by “base version”, but pod.inrupt.com runs ESS. Although I agree that the documentation currently implies that you can use WAC there, which is not the case.
I don’t know about importing from access/universal.
However i tried both your solutions but seems that cannot be imported in the sense that visual code does not describe them when passing mouse over.
Did you try the access import? I think that should be recognised by VSCode. The others need some work on solid-client and an upgrade to the newer TypeScript.
That said, VSCode not recognising them should not obstruct the code from working, although of course it’ll make it slightly harder.
If i use const { access } = require("@inrupt/solid-client");
and pass the mouse over it does not work, but seems that when i try to use access within code it permit me to recall the universal function . Today i will try.
Just a curiosity: when i digit “access” wihtin VS it suggests me access, access_v1 and v2 . Can you tell me more?
Yes, there have been breaking changes to that API, so if you had old code still relying on the previous version, you can import access_v1 rather than just access. It should be irrelevant for you - access is the latest version, and you don’t have old code so no backwards compatibility issues
I ve noticed one thing: when i digit “access.” then VSCode show me the suggestions, but if i call access within setAccess function (as in photo) it tells me just “setAgentAccess”, while if i try immediately after access declaration, VSCode shows me also other interesting things such as if setAgentAccess should be the function within universal_v1, v2, eccc…
Another thing is this:
if i try to import the function i need from @inrupt/solid-client/dist/access/universal_v2, this shows me the code, but when execute it tells me that universal_v2 is not declared/imported/present within the package.json
I m using access/universal now, however i use this syntax,
const {} = require("universal path")
using /access/universal it returns me the fact that i must import as ES module because the “universal” file is a .mjs, while i m using .js , and const {} = require() instead of importing with “import” keyword.
As for the docs, heh, so, PodSpaces actually has its own docs where we do state that it is running ACP. But, definitely, can make a note of it in the JS Client Lib docs as suggested. As well as add more information to our manage access page in the JS client lib docs.
sorry, i don’t have understand this.
However, i changed the fetch parameter as you, but still the same error. I don’t know how to resolve it
@Vincent i m using the last version, i hope ':). I used the npm install @inrupt/solid-client so i think it will return me the latest version
EDIT: I found the error. It was just a conflict with a parameter passed within the function i m using because to set access i pass a “access” parameter. So, when i try to call in the function th e access keyword related to the mechanism of access, it does not know the function setAgentAccess.
Hi @vincenzo-dip8 – to access the acp functions directly, try using the acp_v3 (the deprecation is relative to the universal access APIs – that is the access is preferred over the acp_v3 but to use current acp APIs directly, acp_v3)
Oh, a clarification, The deprecation comment I made earlier - eh, that was a guess on my part. I haven’t had a chance to sort out everything yet - but it was my best guess. Eh.
