Service async function on onProxyReq

[pawelszczerbicki]

Having proxy configured with onProxyReq like:

proxy(gatewayUrl, {
  target: destinationUrl,
  pathRewrite: { [`^${gatewayUrl}`]: '' },
  changeOrigin: true,
  logProvider: () => logger,
  ...options,
  onProxyReq: async (proxyReq, req) => await addAuthHeader(proxyReq, req, redis),
});

Middleware is finishing request before promise is resolved. It is possible to service promise in proxy functions ?

[julkue]

@pawelszczerbicki Having the same question. I will probably use node-http-proxy instead, as there's a documented example for this case.

[magnusp]

I was also looking at making external calls to add/verify authorization headers but came to the same conclusion. I'm guessing that a viable option is to have another middleware do the external call and have it mutate incoming request headers (would transfer over to onProxyReq). But it would be really nice to be able to do this within http-proxy-middleware having matched the route/pattern of the incoming request.

[chimurai]

Looks like there is some demand for async listeners.
I'll consider implementation after some investigation.

@julmot Can you point to the documented node-http-proxy example?

@magnusp Think you can to achieve the same result by chaining middlewares.
Assuming you use express you can write a authValidator and mount it in express like:
app.use('/some/endpoint', authValidator, proxy)

[magnusp]

Im using it via webpack-dev-server which has a configuration property for http-proxy-middleware. The devserver also has a way to setup additional middleware via the "before" and "after" configuration properties. This leaves me having a choice of using my middleware+http-proxy-middleware in a "before" or only setting up my middleware in "before" and using the dedicated "proxy" configuration property. Im mostly mentioning this here for other people stumbling upon the issue and letting them see the options available. But async listeners is an awesome feature. I remember wanting it when implementing a chaos monkey where delays on the proxy were introduced randomly and configurably, at runtime.

[SreeBS]

@chimurai I have to deal with promises in both proxyReq and proxyRes functions. Would be very helpful to have to have these functions support promises.

[montera82]

+1 one for async

how can I achieve using the result of an async call there?

i am doing something like this

onst buildingConfProxyOptions = {
  target: TARGET_BASE_URL,
  changeOrigin: true,
  pathRewrite: {
    '^/building-conf': ''
  },
  async onProxyReq(proxyReq: any, req: any, res: any) {
    const token = req.headers['authorization'];
    const userSvc: UserService = Container.get(UserService);
    const result = await userSvc.verify(token); // Its ending here
// BUT I NEED TO USE RESULT HERE!

  },
  loglevel: 'debug'
};

[shian15810]

For temporary workaround,
I'm doing it like this with promise:

onProxyReq: (proxyReq, req, res) => {
  proxyReq.socket.pause();
  aPromise(a, b).then((c) => {
    proxyReq.setHeader('x-added', c);
    proxyReq.socket.resume();
  }).catch((err) => {
    console.error(err);
    res.sendStatus(500);
  });
},

Or with callback function:

onProxyReq: (proxyReq, req, res) => {
  proxyReq.socket.pause();
  aFunctionWithCallback(a, b, (err, c) => {
    if (err) {
      console.error(err);
      res.sendStatus(500);
      return;
    }
    proxyReq.setHeader('x-added', c);
    proxyReq.socket.resume();
  });
},

Is this plausible at all?

[boxcee]

@shian15810 Did you try? Does it work?

[shian15810]

Yeah, it works!
By plausible I mean does this really make sense?

[magnusp]

Seems reasonable. I'm guessing that the proxyReq.socket should probably be aborted when an error occurs otherwise it could be left hanging until aborted by an timeout in either end.

[shian15810]

@magnusp Do you mean something like proxyReq.socket.end() after res.sendStatus(500)?

Or should it be better off if I get rid of res.sendStatus(500) and use proxyReq.socket.end('HTTP/1.1 500 Internal Server Error\r\n\r\n') instead?

Edited 1:

Just check the source code in express, express's res.sendStatus will trigger res.send within itself and in the end trigger node's http res.end.

Edited 2:

Just tested, socket.resume is not necessary when using res.sendStatus.

[darewreck54]

@shian15810 How did you set the header. When i try to set the header via proxyReq.setHeader('a','g'), i get an exception throwing

Cannot set header after they are sent to the client.

how did you get around that part? I followed the first promise example

Also not sure what the deal is but the res object has not sendStatus() method.....

Thanks!

[shian15810]

@darewreck54 I was having this issue too, and after looking into the source code, at least for me, I couldn't find any way to circumvent this situation, even when using req.headers[customHeader].

But having custom header is essential to the functioning of my application. So finally I decided to change the whole architecture to microservice-based. Sorry, couldn't be much of your help.

If you don't need custom header for your application to be functional, the hack I proposed earlier is still a feasible way to get around the original issue.

Using req.headers[customHeader] won't give you that annoying error, but the header won't reach the upstream server anyway.

[darewreck54]

I actually end up creating my own express middleware that execute the promise and when its successful it will trigger next(). I'll store the updated header in the request and send it to the proxy middleware

[kavitalikesfajitas]

@chimurai did you create a solution to this? Also if not can you provide an example of the authValidator you mentioned?