We are increasing the security of our Webhooks to provide more established and secure connections for our customers and partners. In order to eliminate the possibility for Webhook interceptions and unknown redirections to unauthorized destinations, we will be removing the support of webhooks using indirect URLs that redirect to another URL.
Starting from January 27, 2022 , we will begin to block webhooks that use indirect URL values for the webhook’s subcription_url if it redirects to another destination.
Who is affected?
Anyone who relies on active Webhooks with an indirect URL set as the subscription_url value.
See more in our Changelog for the latest announcements!
Oke, well this kills the hole sync with Google Apps Script (i think for a lot of people) because the doPost(e) is always a redirect link. Nothing we can do about that… Now everybody that want to connect Pipedrive to Google Workspace needs to make a google cloud function (or something similar) to use the webhook, great!
Hi @Remco_CS
Thanks for bringing attention to this case. Unfortunately, there isn’t much we can assist with this situation as this change is done to mitigate any risk to our partners regarding the security of the webhooks.
Hey @Remco_CS & @paulieweb
Thanks for bringing this to our attention. If I understand you correctly, you seem to use the Web App / Script URL as a trigger to receive payloads from Pipedrive webhooks.
Recommended approach
The general recommendation is to use a secure trigger URL (with basic authentication at least) to handle the incoming webhook payload. This URL should also return an appropriate status code if something goes wrong / if the trigger is not accessible.
Like @Remco_CS pointed out, one can use either Google Cloud Functions or AWS Lambda (with a secure HTTP trigger) as a proxy that communicates with the web app URL. This is relatively safe, reliable, and could be an extremely cost-effective approach if the invocations are not that high.
On current setups that rely solely on Google Apps Script (GAS)
There are a few factors that could affect the redirection behaviour. Do you happen to use ContentService to return data in doPost(e)?
If you use ContentService,
the app receives your payload,
executes doPost(e)and then
redirects to some other page to show the content with appropriate status code
Note: This behavior can only be spotted if you make the Postman / REST client not follow the redirects. This would be the case when PD webhooks no longer follow redirections. They will simply see a 302 status code from GAS
Removing the ContentService could eliminate the status code challenge but it opens new challenges. For instance, PD will notice that all webhook triggers return a successful 200 and won’t retry even if there’s an actual failure. Such failures will only be visible on GAS. Also, there’s this constant security threat of having an exposed Web App URL that could be misused (which I would definitely try to avoid )
Hi hem, thank you for the update. I was using the ContentService, but have opted to disable it now. I do follow up on GAS errors daily so this workflow should be okay for me. Thank you again for your assistance.
from GAS
)