Add support for content type "application/json" Webhook requests

[dwc0011]

Is your request related to a new offering from AWS?

Related to Legacy incoming webhooks deprecatation and providing support for the new incoming webhooks which only accept content type "application/json".

Is your request related to a problem? Please describe.

Yes, when creating a new Slack App or Slack Workflow Builder App, integration fails due to content type and json structure (for Workflow Builder Apps).

Describe the solution you'd like.

Implement a non-breaking / backwards compatible solution by adding new Terraform Input Variables that support options for recommended "application/json" content type, parsing to a flat json format (supporting Workflow Builder Apps and custom Slack Apps), and mapping parsed fields to custom variable names. See more details below.

Terraform

1. "content_type_json": boolean true or false (default)

• Defaulting to false will not change anything all new variables are ignored, it is transparent to the user. Providing a non-breaking backwards compatible default configuration.
• If 'true' then the content-type request header will be set to "application/json" and the request url will not be encoded.

2. "create_flat_json": boolean true or false (default). IGNORED if "content_type_json" equals false

• If ignored, payload is current json structure.
• If true, new json parser to create custom flat json key: value structure (Note: Workflow Builder Apps DO NOT support nested json).
• Exact field names will be determined during PR, but as an example - key names (name, description, reason, state_old, state_new, link, etc). Values will be all be type string and all fields whether there is a value or not will be submitted in the POST request, this is a requirement of Slack Workflow Builder apps.

3. "message_map": Optional - map of field names to custom variable names. IGNORED if "content_type_json" equals false and/or "create_flat_json" equals false

• If ignored, payload is current json structure.
• Fields not included in the mapping, are ignored and not included in the request. ONLY fields which are explicitly defined in the "message_map" will be included.
• If null, ALL fields will be included in the request using their default key name as defined in the documentation (included in the PR)

Lambda

1. Add environment variables for CONTENT_TYPE_JSON, CREATE_FLAT_JSON, AND MESSAGE_MAP
2. Add logic to support request call changes based on content type

• If not CONTENT_TYPE_JSON - change nothing
• Otherwise set the content type request header to "application/json" and skip url encoding

3. Implement new parsers to support flat json formatting

• Use the existing parsers as a starting point to determine all fields being parsed and create new parser that captures the same data into a flat json structure

4. Implement parsing the json to the provided message_map structure

• Use this to map the internal names to provided variable names for the json stucture

Documentation

1. All new variables, default values, what they do and how to use.
2. Default field names and values, how to map using the new variables, with examples

Future considerations aka seperate PR:

Implement new BlockKit formatting parsers as described by Slack: https://api.slack.com/messaging/webhooks#advanced_message_formatting

Describe alternatives you've considered.

I tried to create a Slack Workflow App but new workflow apps using incoming-webhooks must be content type "application/json".
Tried other trigger options, using Workflow Builder Apps etc, but the offering is limited and when we created the Webhook for the Workflow Builder App and tried to define json, fields it didn't work as it must be "application/json" and flat json structure

Additional context

More info about legacy incoming webhooks deprecation

How to make a request with new incoming webhooks

[dwc0011]

@antonbabenko I am willing to implement this as a PR but would like to gauge your interest before doing so. I think that it is important to maintain existing functionality to give time for others to migrate until Slack removes the legacy webhooks feature. But also feel that it is as important to provide support for "new" incoming webhooks, custom Slack Apps and Slack Workflow Builder Apps.

Thank you for your consideration and look forward to your response.

[dwc0011]

Just checking in @antonbabenko or @bryantbiggs (I see you are a top contributor, not sure if admin or not) if this issue is something you would consider before I start working the PR.
Thanks!

[bryantbiggs]

I haven't delved into the info you have provided but if you have a PoC or example, I'd be happy to take a look.

More broadly, I don't know what the "ideal" for today is given #254 and this feature request. I think the most helpful thing (before implementation) would be to understand what is the Slack recommended way of doing this today, and what does setting that up look like for users. Once we know that, its not too difficult to work backwards from there to understand what changes need to be made (or changes you are proposing towards this direction)