A firewall is an essential element in network security systems. It secures the organization's internal network and monitors the flow of inbound and outbound traffic based on predetermined rules and protocols.

At times, firewalls tend to block legitimate inbound requests that come in from an unknown source. This is because it is programmed to block all such requests that do not have a genuine source as determined in its protocol.

This might affect system communication, especially if you're using third-party apps that communicate with your internal apps. Contentstack Webhooks communicate with other apps to inform them about some event that occurred in Contentstack. Such requests or triggers can also get blocked by firewalls.

Therefore, in this guide, we will discuss some options that you can use to let the firewalls accept legitimate requests.

Note: To facilitate IP netblocks for receiving webhook callbacks from Contentstack, kindly reach out to administrators authorized by Contentstack. They will provide the necessary guidance in configuring the relevant settings.

Webhooks in Contentstack

Webhooks are URLs invoked by Contentstack to signal events or post data to your third-party application whenever an event occurs in your stack. By sending real-time information, webhooks keep your application in sync with your Contentstack account.

Any firewall mustn't block Webhook notifications; otherwise, your app might not receive timely notifications from taking the next course of action.

Additional Resource: Contentstack's Webhook Integration guide will help you integrate any third-party application to create custom solutions.

Testing and using webhooks is a smooth procedure as long as the connectivity is end-to-end. If the user is developing locally or within a virtual machine that is not publicly accessible over the internet, webhooks get tricky. Development systems don't have public DNS entry which makes it difficult to access them online.

In such cases, the webhooks are not active as the local URLs are publicly not accessible by the app sending the webhooks. Real-time development and request monitoring are not possible in these scenarios.

The intranet or VM system is often protected by the firewall around it, which generally should not use IP addresses. Thus, the webhook cannot get through the firewall that blocks the required ports.

Now, let's understand how Contentstack invokes webhooks on development systems.

Best Practices for Contentstack to Pass Requests Through Firewalls

Here are some of the best practices or the recommendations for letting Contentstack pass requests to your app through the firewall.

1. Use third-party tools to reverse proxy webhook calls
2. Open Contentstack provided IP addresses
3. Simulate the webhooks calls using API development platforms
4. Use polling techniques instead of webhooks

Let's understand each of these in detail.

Using a third-party tool to invoke webhooks is the most common and preferred method used by developers to expose the local server behind firewalls.

Third-party tools for Windows, Linux, and Mac OS, including ngrok and smee, create secure tunnels to access local servers through publicly available endpoints on the internet. ngrok and smee are reverse proxies that make your test system DNS addressable on the internet by penetrating the firewall.

Process overview:

• The Contentstack cloud has two basic environments, i.e., the content management repository to manage and the content delivery repository to deliver the content.
• Whenever we publish content on Contentstack, we're migrating data or updating a flag in the content delivery repository that this version of the entry is updated/ deleted/ live.
• While we publish, if we've configured webhooks, then they can call external reverse proxies like ngrok.
• The CMS and visitors can access our ngrok URL that is publicly available on the internet. We have the ngrok process running on the workstation (local server) inside the firewall, polling ngrok.io to get requests and forward requests on our local host's secure and unsecured ports.
  
  

Additional Resource: For more detailed information, check ngrok's documentation.

Customers who prefer to avoid reverse proxies can use any of the following alternatives.

Developers can open the IP Address of the firewall, which Contentstack provides. Then firewall is open to receive events from the Contentstack provided IP addresses

This practice works well for developers who can administer their firewall and configure DNS to invoke webhooks on their local systems.

By simulating the webhooks calls, we can quickly check if the webhook is functioning internally. Here, instead of having Contentstack invoke the webhooks, we can copy the REST API call of the webhooks and post it to apps like Postman and check the functionality of the webhooks.

Though we get the status of webhooks functionality, this practice invalidates integration testing as we do not use the complete system to test.

The Polling technique is an architectural approach that we can use instead of using webhooks. Most CMS products, including Contentstack, use Sync APIs to check for updates periodically. This is done by setting timestamps to monitor the content at frequent intervals.

While this is an excellent solution for some applications, it does not fit some specific use cases.