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.

Introduction

This article will take you through the four steps required to integrate CrowdHandler with Cloudflare.

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.

Prerequisites

  1. An active CrowdHandler account. If you haven't signed up already you can do so here.
  2. A Cloudflare account.
  3. The domain you intend to protect should be configured as "Proxied" in Cloudflare. DNS only mode will not work.

Step 1: Create a Cloudflare Worker.

  1. Login to your Cloudflare account.
  2. Select one of your Websites:
  3. Select Workers Routes Menu on the Left Navigation
  4. There is a button “Manage Workers” at the top right of the page, click it and proceed to the next step.


  5. From the top right, click the button “Create Application”


  6. On this page, there is a button at the center “Create Worker”, click it then proceed.

     
  7. You can now set your worker name, set it to crowdhandler-integration
    Note: You cannot change the code yet. It’s just a basic worker setup.


  8. Proceed on creating the worker by clicking “Deploy”


  9. Now, Let’s apply the code integration by hitting “Edit Code”
  10. You may able to see the default Hello World code

  11. Copy our integration code from GitHub and paste it into the script.


  12. Click the save and deploy button.



Step 2: Configure the worker variables.

  1. Hit the back button on the script edit page.



  2. Navigate to Settings -> Variables.

  • Add the following variables then click save and deploy.
    1. API_ENDPOINT = https://api.crowdhandler.com/v1
    2. API_KEY = YOUR_PUBLIC_KEY_HERE (Can be found in the Account -> API section of the CrowdHandler administration control panel.)
    3. (Optional) WHITELABEL = false (default) | true
    4. (Optional) NO_BYPASS = YOUR_RANDOM_TOKEN_HERE
    5. (Optional) FAIL_TRUST = false(default) | true
    6. (Optional) SAFETY_NET_SLUG = YOUR_WAITING_ROOM_SLUG_HERE

OPTIONAL VARIABLES

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 Protected Routes.

  1. Using the left-hand navigation click Websites then click the domain you are integrating CrowdHandler on.

  2. Using the left-hand navigation again, select Workers Routes

  3. 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 4: Exclude Routes.

  1. 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. 

"avi","css","csv","eot","gif","ico","jpg","js","json","map","mov","mp4","mpeg","mpg","ogg","ogv","ott","pdf","png","svg","ttf","webmanifest","wmv","woff","woff2","xml".

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 5: 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:

  1. Getting Started (You can disregard the bits about installing the Javascript integration.)
  2. Waiting Rooms
  3. Domain Configuration

Step 6 (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.