Webhooks with URL to internal web server

[Beta] Webhooks
#1

We recently had a need for a new event plugin, and figured we’d try a test with the webhooks to see if it would be a viable path. However, it seems I’m not able to use an internal web sever as the URL? It looks like this was discussed a bit in the Local Server Setup thread, but I wasn’t clear from that topic if this should or shouldn’t be possible.

The server I’m trying to hit is accessible anywhere within our network, and running a Flask site on IIS with FastCGI. We use it extensively for AMIs which have no problems accessing the endpoints, and my hope was the webhook would function in a similar fashion? All my deliveries are responding immediately with the following -

getaddrinfo: Name or service not known
3 Likes
#3

Hi @dan.stein

Thanks for your question! Our application needs to be able to reach the endpoint you supply, to POST the webhooks payload. So if the Shotgun server can’t communicate with your endpoint, it will not be able to deliver the payload. Let me know if that answers your question, or if there’s anything else we can do to help.

Cheers,
Andrew

7 Likes
#4

Thanks @andrew.lawrence!

I think that makes more sense now, I was thinking it over more last night trying to understand why this wouldn’t work the same as the AMIs. My guess is that the AMI is firing the request on the client side in some way so it’s able to communicate with endpoints in our domain? It’s a bit disappointing, since our biggest use case for webhooks would be processing code hosted on local servers, but we’ll have to look into whether any of the other workflows such as AWS will be viable for us.

3 Likes
#5

Hi Dan,

Your reasoning is exactly on the money.

An AMI is triggered by JS code in the browser, whether the AMI be http or a custom protocol. This means it can access resources inside your facility.

Webhooks are triggered by the server and need a route to the supplied URL which in your case is blocked, rightfully so, by your firewall.

If the workflow you’re trying to implement doesn’t need access to internal resources like a render farm or filesystem access it is a prime candidate to leverage webhooks while hosting the business logic on some external host whether that be in your DMZ or something like Heroku or AWS lambda or another service.

If you did implement something in your DMZ you could probably expose some internal resources but I’d be weary about exposing something like the filesystem. Maybe the webhook could poke a web app in the DMZ which in turn populates an internal queue which is exposed to the DMZ and the queue has consumers which can interact with local systems. Maybe that would be secure enough for your security team.

4 Likes