Solid-auth-cli - browserless persistent login


#1

I have just uploaded https://github.com/jeff-zucker/solid-auth-cli which is a browserless version of solid-auth-client which will hopefully be usefull in comand-line scripts, tests, etc. (see Sol - a command line and interactive shell tool for Solid for one use of it).

@RubenVerborgh, many thanks for your software which I seem to like to pirate. Here are some questions for you (and anyone else who cares to chime in)

Any thoughts on the name? It’s built on top of solid-cli and adds to the perfect storm of confusion in that namespace, so I’m more than willing to change it.

And most importantly : how should the two libraries be handled to complement each other? For example, one of the tests I uploaded modifies rdflib’s fetcher.js to conditionally require either solid-auth-client or solid-auth-cli depending on if in a window or not. With that one line change, rdflib becomes able to be used with a persistent login without a browser. It’s been able to do that for reading public materials, but AFAIK, not for writing or for reading private materials. Anyway, it seems that it’s probably not a good idea for me to submit a patch to rdflib (and any other libraries which use solid-auth-client) providing that kind of conditional require. How can this be better handled? Both s-a-client and s-a-cli call each other when in the other’s context? Or a “solid-auth” module which does nothing but switch between the two and would allow for additional auth libraries should they arise?

I have more questions, but that’s enough for now :slight_smile:


#2

Thanks, this is good work, given the current state of node-solid-server.

That said, when node-solid-server will have a more complete OIDC implementation, there is going to be a better way of doing this. Right now, we are basically emulating a browser, but the idea is that apps should perform authenticated requests through tokens. solid-cli has always been a hack (and I should probably document that better), and for that reason I’m hesitant to establish that path too much.

So the long-term answer is: a better OIDC implementation in the server. In the short term: likely ad-hoc solutions such as these.


Allow app developer to use advanced server-side feature
#3

Thanks, I needed that kind of an overview. I’ll concentrate on getting these workable as transition helpers and not expect them to be part of the eventual landscape.


#4

Although I understand that what I’m aiming for is a total hack, I believe that giving new developers additional ways to interact with core tools like rdflib is a valid short term goal. So, a less grandiose question than above : do you have any suggestions as to the best way to substitute solid-auth-cli for solid-auth-client as the fetcher’s auth in rdflib when it is used in a browser less context?