The idea is:
Many services offer verification of the requests to ensure the message comes from the legitimate source. The verification process is different by different vendors. However, quite often you would need a raw data to hash and match against the signature that comes with the request payload.
My use case:
I wanted to engage verification process for Slack initiated requests. The process requires the raw data (as well some other values from the payload) to hash with the signing secret.
However, the payload outputed by the Wedhook node is presented deserialized in the form of JSON. Applying the Slack signing secret will never work as the data has to be in the raw format.
The raw format for Slack data conforms to the content type " application/x-www-form-urlencoded". That is, the raw data is expected to look like this
token=xyzz0WbapA4vBCDEFasx0q6G&team_id=T1DC2JH3J&team_domain=testteamnow&channel_id=G8PSS9T3V&channel_name=foobar&user_id=U2CERLKJA&user_name=roadrunner&command=%2Fwebhook-collect&text=&response_url=https%3A%2F%2Fhooks.slack.com%2Fcommands%2FT1DC2JH3J%2F397700885554%2F96rGlfmibIGlgcZRskXaIFfN&trigger_id=398738663015.47445629121.803a0bc887a14d10d2c447fce8b6703c
as opposed to its deserialized version in JSON.
It would be great if the Webhook node had an extra property presented, rawBody (or similar), containing the original data representing the body of POST payload.
I am aware that there is an option to present the “Raw Body” (binary) in Wenhook node. However, this is a different kind of data representation. It does not allow to see the actual string containing the raw data representing the body string in HTTP POST request. I would like to see this string as an additional property in the JSON, for example,
{
"headers": {},
"params": {},
"query": {},
"body": {},
"rawBody": "" // additional property
}
I think it would be beneficial to add this because:
It’s important to keep the environment secure and ensure only legitimate requeets get processed.
I tried to serialize the JSON in attempt to reproduce the original raw data but that turned out to be unreliable and does not work every time. The problem is that encoding does not necessarily conforms to the output of such JS functions as encodeURIComponent(), for example. In particular, this function encodes space as %20 but Slack uses + instead, etc.
Having the actual access to the raw body would resolve the problem of the signature verification.