This was really poorly handle, it seem like you guys didn’t think about 3rd party like github, with this new change it is not possible to to use github, as you can’t set the X-Automation-Webhook-Token in header for posting to webhooks. What are we suppose to do for github?
The option to still use the previous web hook process must be re-enabled or provide a way to toggle custom headers as a requirement.
This stance is unacceptable from Atlassian.
“Newly created rules with incoming webhook triggers needs X-Automation-Webhook-Token, as it is pointing to a different endpoint. Unfortunately, there is no way around without passing this header, and Dialpad needs implement changes to their product to allow custom headers.”
pushing the responsibility for vendors to commit time and resources to changes shouldn’t be the answer here.
With this change, we can no longer create new incoming webhooks from GitHub. I understand the security reason behind this, but you should have considered some key third parties before rolling out this breaking change. There’s no option to add an extra key to the headers (X-Automation-Webhook-Token) when creating a webhook.
Updated from the regular community post (Update on Incoming Webhooks Trigger for Atlassian ... - Atlassian Community)
Some of you have encountered challenges with using custom HTTP headers in your applications, particularly when it comes to adding the header
X-Automation-Webhook-Token
when you send the secret. This may occur if your connected application doesn’t support custom HTTP headers.If you’re encountering this problem, you can insert a slash at the end of the URL and add the secret after this. For example,
https://URL/SECRET
. This will allow you to update your rules without the need for a HTTP header. However, we recommend using the header if possible, as it provides more security for your secret.
Passing secrets as part of the url? I’m not sure if this is considered best-practices.
But anyway, it feels like building solutions / workarounds around the limitations due to the design decision to run Forge apps in AWS Lambda and web triggers maybe are just Lambda Function URLs.