Building a node proxy - solid-auth-client

I’m trying to build a pass-through proxy capable of accessing private data on Solid. I’m working with solid-auth-client in the browser. Tested first fetching directly from Solid rather than through the proxy. Works fine. Interacting with both sides https works fine.

The web page is served by the same server that proxies. The simple pass-through works for public data but not for private data. So I’ve been experimenting by first passing information from the connection request via an agent and then requesting a file with https.request. Solid isn’t even getting the agent name; i.e. agent null (two different uses of the word agent).

I don’t really know how solid-auth-client passes that information. Am I on the right track?

Are you aware of my work on Solid-Rest and Data Kitchen which provide a pass-through proxy for a local file system, ssh hosts, in-browser storage, and has a pluggable backend for other storages? I am finalizing Solid-Rest-Server right now which wraps that all in an httpd.

And I definitely suggest not using solid-auth-client. It is deprecated. Solid-client-authn-browser is the future. The future of Solid auth is in the newer DPoP token which solid-auth-client does not handle. Solid-auth-client also stores its tokens in the browser localStorage which is a security problem so the entire way tokens are passed that it uses is obsolete. It was the workhorse for years, but now it’s retired.

This soon-to-be released branch of Solid-node-client wraps solid-rest for use in nodejs scripts and command-line. This branch of it can use either solid-client-authn-node or solid-auth-fetcher (both of which use the new DPoP token) to make authenticated requests.

1 Like

Thanks Jeff. I know I need to update. I had solid-auth-client working directly in the browser before I knew that I should update so I was just using what I had in my experiments. I intend to continue also with back-end interaction as soon as I get the proxy released. It would be very nice to work instead with what’s best now that would work in both.

My proxy is designed for use by an, easier than Express, server that I built for use in a beginning programming course. The core of the proxy should be lean and mean and I’ll open source it - free software. The proxy is a DIM project, even if it eventually seems to have only been for the sake of learning something new.

Getting the best Solid module to work with is something I’m very interested in. Then I just need to know how to pass the essential information through the proxy.

Well you can either just use Solid-Node-Client because it already handles the auth, or look at it’s code to see how it does that by wrapping the actual auth libraries.

I’m glad to answer questions if you dig into that code and need suggestions.

I have been thinking that I should switch to solid-node-client based on your previous recommendation. I’ll do that tomorrow and begin anew. I’m sure I even still have the page in a browser tab. :slight_smile:

The npm version should work for what you need the branch I mentioned above only adds ability to use ESS/CSS servers.

I wound back a bit. Using different packages looks like other projects. My working assumption is that if I can get the proxy to work using solid-auth-client, then it should work for anything and I really want to get a release of the proxy out the door. So, I’m still using solid-auth-client for now. I have been looking through headers and as mentioned above, done some experiments trying to pass-through on connection first, but haven’t cracked it.

Below is a very simple pass-through. The web page uses solid-auth-client. The simple proxy works for public resources. My web page – when not going through the proxy — can get private resources. What do I need to pass through in order to get private resources through the proxy?

const target = {
  protocol: 'https:', 
  hostname: '', 
  port: 7443, 
  method: 'get'
//   path: "/public/hello.txt",

let server = https.createServer(options, proxyApp).listen(8440);

function proxyApp (request,response) {
  console.log("URL: " + request.url);
   if (request.url == '/index.htm' || request.url == '/solid.js') {  // solid.js makes solid-auth-client calls
   } else {
function runProxy (request,response) {
    let req = https.request(target, function (res) {
      res.pipe(response, { end: true });
    .on('error', e => {
      console.log("req on error " + e.stack);
    target.path = request.url;
    request.url = target.protocol + '//' + target.hostname + ':' + target.port + request.url;
    request.pipe(req, { end: true });

early release version of proxy announced:

I continue to work on this and thought I’d update because it may clarify what I need. I started this knowing almost nothing about OIDC etc. so it is a learning trip.

The proxy itself is intended to be a simple pass-through that does not authenticate anything. The idea is that the process takes place between the original client (I’ve been working with solid-auth-client in the browser) and the Solid Server. This should also explain my belief (perhaps naive?) that this shouldn’t be impossible even though I’m not an expert in authentication etc.

I’ve been reading up on OIDC, JWT, and other things while inspecting request and response objects for any clue as to what needs to be passed through. I can see that the JWT information is in the Session object that is returned at login. Not seeing any of that information show up anywhere else.

I also understand that OIDC does not have one standard fixed way of sending the information - it can for example be passed as a cookie, or in the request header, or in the body.