[Server] allow addition of middleware BEFORE default middlewares (for Stripe Webhook Verification)

[vincanger]

At the moment, when trying to verifying the signatures sent by stripe in the request headers, its not possible because express.json mutates the request. Stripe needs the raw request body in order to verify signatures. This can be accomplished like so:

app.use('/stripe-webhook', express.raw({ type: '*/*' })); // <---- VERY RAW
app.use(logger('dev'))
app.use(express.json())
app.use(express.urlencoded({ extended: false }))
app.use(cookieParser())

app.use('/', indexRouter)

but the raw request must come through first, before being parsed by the JSON middleware: https://stripe.com/docs/webhooks/signatures

[santolucito]

Looks like this can be solved in this way:

https://github.com/wasp-lang/open-saas/blob/8e3199cc38d5219da7402bf607952c26619d53f8/template/app/src/payment/stripe/webhook.ts#L55

Recommend closing the issue

[vincanger]

As @santolucito mentions, this is solved (as is being done in the Open SaaS stripe webhook) by first deleting the default config, then adding the desired one, like this:

export const stripeMiddlewareFn: MiddlewareConfigFn = (middlewareConfig) => {
  middlewareConfig.delete('express.json');
  middlewareConfig.set('express.raw', express.raw({ type: 'application/json' }));
  return middlewareConfig;
};

But would it make more sense that when consuming a user's MiddlewareConfigFn we just inject it at the top of the middleware stack, since express executes middleware functions in the order they are applied? This way, the user has to know less about Wasp's default middleware config. Or would having the 'express.json' function still exist within the middleware execution cause issues?

[Martinsos]

Hm interesting, looking at the code here https://github.com/wasp-lang/wasp/blob/main/waspc/data/Generator/templates/server/src/middleware/globalMiddleware.ts, it seems that we don't currently care much about the order of the middleware actually -> we turn that Map into Array and just apply those in order.

MDN says
| A Map object iterates entries, keys, and values in the order of entry insertion.
so that is what happens. But that also means users will usually add "at the end". Unless they delete they entry and then add a new one. Or well they could construct a new Map whatever way they like really! So they do have full control actually, it is just not documented as to how Wasp cares about the order of the middleware in that Map.

We should add to docs that middleware from that config will be applied in the order it is iterated in the Map, which is by the time of entry. I can create a quick issue for that.

[Martinsos]

Ok, I made a quick PR here to improve the docs: #2263 -> have yet to make it fix correct docs but this can serve as a start for now.