Our Cloudflare integration utilizes Cloudflare's edge code solution Cloudflare Workers to provide you with a waiting room service that works directly from your CDN without the need for you to make any changes to your application code or web servers.
This article will take you through the four steps required to integrate CrowdHandler with Cloudflare.
- Steps 1-3 will guide you through installing and configuring the worker.
- Steps 4-5 demonstrate how to enable CrowdHandler protection on your chosen routes.
- Step 6 provides references to articles that will help you configure your waiting rooms through the CrowdHandler control panel.
If at any point of working your way through the guide you get stuck or have questions then feel free to reach out to us via https://support.crowdhandler.com.
- An active CrowdHandler account. If you haven't signed up already you can do so here.
- A Cloudflare account.
Step 1: Create a Cloudflare Worker.
- Login to your Cloudflare account.
- Select the Workers service.
- If this is your first time creating a Cloudflare worker you will be prompted to set up a free Cloudflare worker subdomain and to choose a worker plan. You can name your subdomain whatever you want and proceed to choose your plan.
For the purpose of working through this setup guide, the free plan will suffice. If required, It is possible to upgrade to the paid, workers plan once setup is complete (see Step 5).
- Click create a Service.
- Create your service. You should name it crowdhandler-integration
- Hit the Quick Edit button
- Remove the default template code so that the script is empty.
- Copy our integration code from GitHub and paste it into the script.
- Click the save and deploy button.
Step 2: Configure the worker variables.
- Hit the back button on the script edit page.
- Navigate to settings -> variables.
- Add the following variables then click save and deploy.
- API_ENDPOINT = https://api.crowdhandler.com/v1
- API_KEY = YOUR_PUBLIC_KEY_HERE (Can be found in the Account -> API section of the CrowdHandler administration control panel.)
- (Optional) WHITELABEL = false (default) | true
- (Optional) NO_BYPASS = YOUR_RANDOM_TOKEN_HERE
- (Optional) FAIL_TRUST = false (default) | true
- (Optional) SAFETY_NET_SLUG = YOUR_WAITING_ROOM_SLUG_HERE
WHITELABEL (default false) By default, users will be queued on CrowdHandler's wait.crowdhandler.com domain. If WHITELABEL is set to true, users will be queued on the domain CrowdHandler is protecting. For example, if CrowdHandler has been set up to protect www.example.com, users will be queued on the www.example.com/ch/ path. The /ch/ route does not need to exist in your application.
Read more about whitelabel waiting rooms here.
The NO_BYPASS value will be sent to your origin as the value of the x-ch-no-bypass header. You can check for this header in your application to verify that the request has traversed through CrowdHandler. Implementation examples can be found in the "Integration Examples" section of this article.
FAIL_TRUST (default true) By default, users that fail to check in with CrowdHandler's API will be trusted. If set to false, users that fail to check-in with CrowdHandler's API will be sent to a safety net waiting room until CrowdHandler is able to make a decision on what to do with them.
Read more about Trust on Fail here.
If SAFETY_NET_SLUG is defined and FAIL_TRUST is set to false, this waiting room slug will be used as the safety net room. If you do not define a SAFETY_NET_SLUG value and FAIL_TRUST is set to false, a generic waiting room template will be used as the safety net room.
You can find your waiting room slug in the CrowdHandler control panel in the URL field of your room configuration.
Step 3: Configure Worker Trigger.
- Navigate to the triggers tab.
- Click the Add Route button.
- Add the following trigger (more specific route configuration will be done in the next step).
Step 4: Configure Protected Routes.
- Using the left-hand navigation click Websites then click the domain you are integrating CrowdHandler on.
- Using the left-hand navigation again, select Workers Routes
- Add the route you would like to protect.
The above pattern will trigger the CrowdHandler worker for all routes on your site except for any excluded routes that you configure in the next step. We recommend starting off with this pattern unless you're confident that your site won't be flooded with traffic to unprotected routes.
You can do further, more granular waiting room route configurations through the CrowdHandler admin console.
Step 5: Exclude Routes.
- Exclude routes that should not have CrowdHandler protection by adding additional routes selecting "None" in the worker dropdown.
Out of the box CrowdHandler will automatically not attempt to queue routes with the following file extensions.
It is your responsibility to ommit patterns and routes that should not be queued.
Common examples are:
* Paths used for storing static assets and media i.e. /wp-includes/*
* Callback URLs made by third party payment providers.
* JSON and RSS feeds.
Step 6: Finalise your configuration.
CrowdHandler is integrated with your Cloudflare account and now it's over to you to customize your CrowdHandler setup through the CrowdHandler administration console. Here are some recommended support articles that cover the basics:
- Waiting Rooms
- Domain Configuration
Step 7 (Recommended): Remove Cloudflare Workers Rate Limiting.
At the time of writing the Cloudflare workers free plan is subject to a burst rate limit of 1000 requests per minute and a daily request limit of 100,000 requests. If you think that these limits might be too low for you, we would recommend upgrading to the Cloudflare workers paid plan to remove the limits.