# Solid-auth-cli - browserless persistent login

**URL:** <https://forum.solidproject.org/t/solid-auth-cli-browserless-persistent-login/1016>\
**Category:** Solid App Development FAQs\
**Created:** [January 8, 2019, 10:31pm UTC](https://forum.solidproject.org/t/solid-auth-cli-browserless-persistent-login/1016 "2019-01-08T22:31:35Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jeffz](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/jeffz/32/600_2.png) [@jeffz](https://forum.solidproject.org/u/jeffz)\
**Post date:** [January 8, 2019, 10:31pm UTC](https://forum.solidproject.org/t/solid-auth-cli-browserless-persistent-login/1016/1 "2019-01-08T22:31:35Z")

</div>

I have just uploaded **[https://github.com/jeff-zucker/solid-auth-cli](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](http://forum.solidproject.org/t/sol-a-command-line-and-interactive-shell-tool-for-solid/1005) 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 🙂

---

<div class="post-metadata">

**Author:** ![jeffz](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/jeffz/32/600_2.png) [@jeffz](https://forum.solidproject.org/u/jeffz)\
**Post date:** [January 9, 2019, 1:54am UTC](https://forum.solidproject.org/t/solid-auth-cli-browserless-persistent-login/1016/3 "2019-01-09T01:54:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jeffz](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/jeffz/32/600_2.png) [@jeffz](https://forum.solidproject.org/u/jeffz)\
**Post date:** [January 9, 2019, 6:05pm UTC](https://forum.solidproject.org/t/solid-auth-cli-browserless-persistent-login/1016/4 "2019-01-09T18:05:27Z")

</div>

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?