Hello everybody,
I would like to ask you for advice on how to deal with this problem.
For the Master’s Thesis (Switzerland), I developed an application that interacts with the Solid environment (Inrupt). In December 2021 I ran the last tests, and everything was working fine.
Now (March 2022) I have returned to develop, and the application is no longer able to interact with Solid returning me the error 401 Unauthorized access. This happens for all the operations that I had implemented. Also, through a check on the code, I can see that the login is done correctly! (for login I use the @ generate-oidc-token utility)
I am no longer able to perform operations, not even as a Pod administrator.
** Premise **: The code has not changed since the last functional test of December 2021. I only generated new keys with the utility and tried to run the application.
I thought it might be a library version problem.
the thing I was able to notice is this:
I can interact with the containers I created in December, while if I want to try to create new containers (as admin) I get the 401 error
It sounds from the fact that you are using generate-oidc-token that you are using a nodejs script rather than operating in the browser. If that is the case, what error message do you receive? Is it an error logging in or you are logged in and get the 401 anyway?
I just did some experimenting with @inrupt/solid-client-authn-node 1.11.6 and as far as I can see the token generated by @inrupt/generate-oidc-token from inrupt.com is good for only one run of a script, it must be regenerated every single time you run the script. @zwifi or @nicolasmondada, can you confirm?
The utility permit me to login correctly. About the validity of the token generated, you are right. However i could tell you that if you use the utility to obtain token from the solidcommunity.net server, the same token will be valid for more sessions. I find this during several tests.
Now, as i said above, the utility work as well. However, when i try to create new context, new container (in the same way i did in December) this return me 401 unauthorized access, as if i not allowed to execute that action. This happened also if i try to create new dataset or new policies.
In the previous response i said that i can interact with pods and solid only when i use the content within the container already created in December.
Yes, the token at inrupt.net and solidcommunity.net (both of which use the NSS solid server) last longer than that of inrupt.com (which uses the ESS solid server). One thing you can do is give your NSS WebID rights to all your ESS pod, then login on NSS and access your ESS data that way.
The fact is that:
my application could interact with Solid either during its execution or through the initialization option (-i) served by the script itself.
Initialization allows me to create a series of containers and upload the files I need. You must use the admin ID (who should have all the permissions for your Pod). Trying the initialization, I always get the error 401, which is strange as I’m acting as an administrator! Also, I confirm that I can log in with the utility for the token, so I do not understand the reason for the 401 error.
While, the normal execution of the application works well, with all the necessary controls on the accesses made. However I am forced to use the Pods created previously (December), because as already mentioned, I have no possibility to create new containers, new rules, new datasets …
Before this problem, i was able to:
execute all actions i need
login both as admin (ESS) and guests (NSS)
create every time a new context simply by changing the path/directory name
In general there’s many different potential 401 errors (due to how the oAuth / OpenID Connect logic works), so we’d need to know more about the errors coming out to assist further, I think.
Other than that, I’d be checking that I’m using the latest versions of the SDK as there have been many improvements ovef the past 3-5 months.
Regarding the last statement, i preferred to not update the SDK since the last time (December) it works fine. Also to not incur in change on some functions that i have re-implemented.
As in the images below, i m trying to execute some action, but starting with a login. We should be able to look the correct authentication (first image).
Both the images highlights 401 error, but seems the twos are related to different part of “index.js” file.
I’d highly suggest upgrading, as there’s a lot of bugfix and security updates in there. But, if you’ve just edited the package after you’ve installed in in node_modules, then I’d highly recommend looking at using patch-package which makes maintaining such modifications much easier.
I would take a guess that the 401s you’re seeing are due to the token being presented not being validate, e.g., expired, lacks dpop, dpop signature mismatch, or client_id is invalid, or redirectUrl doesn’t match client’s redirectUrl’s.
I would definitely be curious as to what modifications you’ve made to the Inrupt SDK, maybe we’ve missed an API or miss-documented something, and that way we could potentially improve for everyone.
more than a “patch” to the library, i ve tried to implement an interface to the API, but as testing purposes.
The token cannot be invalidated, because i generated before executing the script!
If i use a previous (December) created directories/Pods, the token generated works fine, using the same process of generation.
