Announcing Solid-Node-Client

41

One thing to consider is that Solid Node Client supports alternate auth libraries. By default it uses Solid Auth Fetcher which requires you to register solid-node-client as a trustedApp. However if you use Inrupt’s Solid-Client-Authn-Node as the auth (see Solid-Node-Client README) you don’t need to add a trustedApp. The process for obtaining an OIDC auth token is much more cumbersome, but there is no guarantee (and in fact it is unlikely) that future Solid servers will provide a command-line login using username/password so the OIDC token flow is more generally useful.

42

On the other hand @bourgeoa - maybe NSS could offer https://solid-node-client as a default trustedApp which would simply put us back to the way things were with solid-auth-cli - that the server automatically accepted command-line apps with no origin as trusted.

43

Yes that would be very helpful and solve my major issue with the authentication flow. I was using solid-auth-cli for my development which had no issue like this. Since the introduction of the new tokens i have been trying to migrate to solid-node-client with no avail. Is it advisable to continue development using solid-auth-cli for now?

1 Like
44

I am not sure using PATCH to profile/card will work.

You could try PATCH with text/n3 or application/sparql-update solid-file-client PATCH

You must produce triples like this :

:me acl:trustedApp
            [
                acl:mode acl:Append, acl:Control, acl:Read, acl:Write;
                acl:origin <yourTrustedApp>
            ],
45

Yes, unless @bourgeoa agrees to that NSS fix, probably, sticking with solid-auth-cli makes the most sense since it should continue to work with NSS. The changes to solid-node-client were necessary for it to work with ESS and other servers. All these changes are an unfortunate but necessary part of developing apps at the same time the spec and servers are evolving. You might want to revisit the choice in a few months when the dust has settled a bit in terms of the whole login/token process.

1 Like
46

Could you open an issue so that it can be discussed.

1 Like
47

Yes it was in the old days where the origin problem did not exist.

48

Sure, thank you. I will continue to use solid-auth-cli for now.

49

Or just an option to add default trusted apps during the creation of the server would be nice.

50

Just tried PATCH with application/sparql-update and it does work applied to a .ttl file

@prefix n0: <http://www.w3.org/ns/auth/acl#>.
    INSERT {:me n0:trustedApp
        [    n0:mode n0:Append, n0:Control, n0:Read, n0:Write;
             n0:origin <https://bourgeoa.ga:8560> ]. }
1 Like
51

This worked, thanks a lot. I can now use solid-auth-cli just during registration to add node-solid-client as a trusted app and then continue to use solid-node-client for the rest. Please let me now where i can keep an eye on the development of this issue so i can stay updated.

52

Hello, @jeffz @bourgeoa,

I am trying to use rdflib’s “updater.addDownstreamChangeListener” combined with node-solid-client to listen to changes in a file in my node js app. But I am having trouble listening and logging changes using event emitters.
Any directions on using updater.addDownstreamChangeListener or using a WebSocket in a nodejs backend to listen to changes in data web would be appriciated.

53

I’m afraid I don’t know much about WebSockets. My understanding is that currently different Solid servers have varying WebSocket capabilities. As far as I know, using updater.addDownstreamChangeListener should work the same in solid-node-client as using it with a different fetch, but if you are running into errors, maybe post them and I’ll take a look.

54

Hi, i usualy use Websocket on Solid browserSide this way https://github.com/scenaristeur/ipgs/blob/6b8437d23c3812ee87671ca28051a85e0df02002/src/components/layout/Notification.vue#L24

And i think you could adapt it with GitHub - websockets/ws: Simple to use, blazing fast and thoroughly tested WebSocket client and server for Node.js

55

let link = store.sym(http://url)

const chat = link.doc()

let from = store.sym(<http://url1>)

let fr = from.doc()

let data = await fetcher.load(chat).then(response =>{

    let msg = store.any(fr, as('Document'))

    console.log(msg, response)

})
console.log(data)

async function refreshFunction(){

    let msg = store.any(fr, as('Document'))
    console.log(msg)

}

updater.addDownstreamChangeListener(chat, refreshFunction)
56

@jeffz @bourgeoa Hello,
I am using solid-node-client by adding the client in my index.js as

const client = global.client = new auth.SolidNodeClient();

The first user login works fine. But when a second user logs in to the pod the previous user gets unauthenticated. I am Loggin in the user like this in my login route

global.client.login(cred).then(solidSession => {
}

and i am initiating my fetcher as

const fetcher = $rdf.fetcher( store, {fetch:global.client.fetch.bind(global.client)} );

Is there a step I am missing to persist each user’s login session?
Thank you for your time

57

You can not have multiple identities logged in on one client. So just create one client for each user, login as that user with that client and then it should persist. See the section on multiple clients in the README.

58

could you please give an example of how i would go about doing this. Since the client has to be initiated as a constant, i will not be able to assign the name of the client based on another variable like a username. what logic should i be using to create a new client for each user so it could be used through out the application

59

I’m not sure how to answer without knowing more about why you need the constant. Why not a global variable that isn’t declared as a constant?

60

var client = {};
//… later
client[‘naveen’] = new SolidNodeClient();
client[‘jeff’] = new SolidNodeClient();
client[‘naveen’].login();
client[‘jeff’].login();

1 Like