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?
2 Likes
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.
1 Like
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.
1 Like
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-Tokenwhen 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.
5 Likes
Hello guys,
we have just switched to create incident tickets for our addon “Jira Email This Issue” by firing a webhook against an automation in Jira.
It basically works, the automation is triggered, we can parse each attribute in the transmitted JSON.
The addon webhook itself gets a strange response though. It says there “no JSON input found”.
In the addon, we do not use the https://URL/SECRET trick, we past in a custom request header section the two lines for Content-Type and X-Automation-Webhook-Token.
Does someone gathered experiences with that behaviour in the connected apps and why it acts like that, since the automation is triggered correctly?
Hello,
FYI, when adding a Jira webhook into BitBucket, the header is also missing, resulting in the same status 400 “missing token”.
Adding the secret at the end of the url works.