Integración con Cloudflare: primeros pasos

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.

En este artículo te explicaremos los cuatro pasos necesarios para integrar CrowdHandler con 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.

Requisitos

  1. An active CrowdHandler account. If you haven't signed up already, you can do so here.
  2. Una cuenta de Cloudflare.
  3. El dominio que deseas proteger debe configurarse como «Proxied» en Cloudflare. El modo «Solo DNS» no funcionará.

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. Selecciona uno de tus dominios:

  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. Pulsa el botón «Atrás» en la página de edición del 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) | verdadero
    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 | verdadero (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 verdadero) — 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 aquí.

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. Añade la ruta que te gustaría proteger.

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.

Puedes realizar configuraciones más detalladas de las rutas de la sala de espera a través de la consola de administración 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.

Paso 4: Excluir

  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 devolución de llamada generadas por proveedores de pago externos.
  • Formato JSON y fuentes 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. Salas de espera
  3. Configuración del dominio

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?