Intégration de Cloudflare - Pour commencer

Our Cloudflare integration uses 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.

Cet article vous guidera à travers les quatre étapes nécessaires à l'intégration de CrowdHandler avec 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 our support site.

Conditions

  1. An active CrowdHandler account. If you haven't signed up already, you can do so here.
  2. Un compte Cloudflare.
  3. Le domaine que vous souhaitez protéger doit être configuré en mode « Proxied » dans Cloudflare. Le mode DNS uniquement ne fonctionnera pas.

Note: Protecting a WordPress or WooCommerce site? Make sure to set ORIGIN_TYPE = wordpress in Step 2 of the guide.

Step 1: Create a Cloudflare Worker

  1. Log in to your Cloudflare account.

  2. Select Domains in the left-hand navigation.

  3. Sélectionnez l'un de vos domaines :

  4. Select the Workers Routes menu in the left-hand navigation.

  5. There is a button, "Manage Workers", at the top right of the page. Click it and proceed to the next step.

  6. From the top right, click the button "Create Application".

  7. On this page, choose "Start with Hello World!".

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

  9. Proceed to create the worker by clicking "Deploy".

  10. Now, let's apply the code integration by hitting "Edit Code".

  11. You will be able to see the default Hello World code.

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

  13. Click the "Deploy" button.

Step 2: Configure the Worker Variables

  1. Cliquez sur le bouton « Retour » sur la page d'édition du script.

  2. Navigate to Settings → Variables.

  3. Add the following variables as plain text, 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) | vrai
    4. (Optional) ORIGIN_TYPE = wordpress (set this optional variable if you are protecting a WordPress or WooCommerce website)
    5. (Optional) NO_BYPASS = YOUR_RANDOM_TOKEN_HERE
    6. (Optional) FAIL_TRUST = false | vrai (default)
    7. (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.

ORIGIN_TYPE — Set value to wordpress if you are protecting a WordPress or WooCommerce origin. This will exclude URL requests matching the following regex pattern from CrowdHandler API checks: /(wp-.*|wc-.*|xmlrpc\.php|readme\.html|license\.txt|trackback|feed(?:\/.*)?|comments\/feed(?:\/.*)?)(\?.*)?/

NO_BYPASS — 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 vrai) — 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 ici.

SAFETY_NET_SLUG — 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.

COOKIE_DOMAIN — By default, the CrowdHandler cookie is host-only. Set COOKIE_DOMAIN to a parent domain (e.g. example.com) to share it across subdomains — useful when queueing on www.example.com and validating sessions on api.example.com. Must be a parent of the worker's hostname; invalid values are ignored.

IP_HEADER — By default, the worker reads the client IP from Cloudflare's cf-connecting-ip header. If your traffic reaches Cloudflare via an upstream proxy (e.g. zScaler, Imperva) that inserts the original client IP into a different header, set IP_HEADER to that header name (e.g. x-forwarded-for) to source the IP from there instead. For multi-value headers, the left-most entry is used. If the configured header is missing, empty, or anything goes wrong during parsing, the worker safely falls back to cf-connecting-ip, so existing deployments are unaffected when this variable is unset.

Important: only enable this when your traffic is guaranteed to traverse a trusted upstream proxy you control.

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. Ajoutez la voie que vous souhaitez sécuriser.

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.

Vous pouvez définir des configurations plus détaillées des parcours dans la salle d'attente via la console d'administration de CrowdHandler.

IMPORTANT

If you choose to protect a more specific route, for example *tulipmania.net/enroll-now, AND you have set the optional variable WHITELABEL to true, you should add an additional route covering *tulipmania.net/ch*. Without this route the Cloudflare worker won't trigger to render the waiting room.

Étape 4 : Exclure

  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 omit patterns and routes that should not be queued. Common examples are:

  • Paths used for storing static assets and media, i.e. /wp-includes/*
  • URL de rappel générées par des prestataires de paiement tiers.
  • Flux JSON et RSS.

Step 5: Finalize 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. Salles d'attente
  3. Configuration du domaine

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 recommend upgrading to the Cloudflare Workers paid plan to remove the limits.

Step 7: Performing a Simple Integration Test

After your configuration steps are finished, we recommend a functional test of your setup as described in the guide here: How do I test the waiting room?