Added type check to webhook signature

[tbobkermux]

I've implemented a conditional check to see if the signature header is a string or if it is an array and removed the error to upgrade axios package to the latest version.

[erikpena]

Would of helped if I click the "submit review" button 🙄

[dylanjha]

This is unrelated to the PR, but I noticed we're doing JSON.stringify(body) here to get the raw webhook request body. Is there a way we can access the raw body directly?

Webhooks.verifyHeader(JSON.stringify(body), sig, config.webhook_signing_secret);

This is potentially problematic because of the following scenario

1. Mux creates the signature based off the raw stringified JSON body
2. The webserver that receives the request parses the string and turns it into a JSON object
3. Application code does JSON.stringify on the JSON object to convert it back into a string

The problem is that the string in (1) and the string in (3) should be the same, but they're not guaranteed to be, and if they are not exactly the same, then the signature verification will fail.

Getting the raw request body eliminates the risk of this.

This is a common problem, and we document how to handle this in the node SDK: https://github.com/muxinc/mux-node-sdk#verifying-webhook-signatures and the elixir SDK: https://github.com/muxinc/mux-elixir#usage-in-phoenix

[erikpena]

This is unrelated to the PR, but I noticed we're doing JSON.stringify(body) here to get the raw webhook request body. Is there a way we can access the raw body directly?

Webhooks.verifyHeader(JSON.stringify(body), sig, config.webhook_signing_secret);

This is potentially problematic because of the following scenario

1. Mux creates the signature based off the raw stringified JSON body
2. The webserver that receives the request parses the string and turns it into a JSON object
3. Application code does JSON.stringify on the JSON object to convert it back into a string

The problem is that the string in (1) and the string in (3) should be the same, but they're not guaranteed to be, and if they are not exactly the same, then the signature verification will fail.

Getting the raw request body eliminates the risk of this.

This is a common problem, and we document how to handle this in the node SDK: https://github.com/muxinc/mux-node-sdk#verifying-webhook-signatures and the elixir SDK: https://github.com/muxinc/mux-elixir#usage-in-phoenix

Great question. What I can say is that Strapi's request apis are based on Koa.js (https://koajs.com/). It might be possible to capture the raw body and grab the string up front. That would have to be looked at. But I agree, it's possible that stringifying a json object might change the order of the properties.

[erikpena]

Quick update, so the webhooks bit looks like it is addressed. However, and with more concern, it seems that something has changed with how Strapi handles plugins and exposing settings in the admin dashboard. What's happening is that "General" links in the Strapi dashboard will show initially allowing a user to go in and configure Strapi (including the Mux Video Uploader). However, after saving, the whole "General" section on the left menu of Strapi disappears. This includes Marketplace, Plugins and all of the settings (not just Mux Video Uploader).

We've reached out to Strapi to see if we can get some understanding as to what is happening here. Will keep this thread apprised!

[erikpena]

With Strapi's help, we were able to resolve the permission issues and it's working 🎉 .

In summary, here is what we've done:

• Added typing to resolve issues with Typescript compiling Koa.js types (error TS2339: Property 'body' does not exist on type 'Request' #5)
• Updated webhookhandler to handle new type provided by Koa.js (install fails using strapi 3.5.x #6)
• Updated peerDependency for Strapi for 3.6.2
• Updated dependencies to use appropriately versioned dependencies

@tbobkermux could you run through some testing before we merge this in?