Exploiter le front end sur Cloudflare

PLUS Un front end qui lit l’interface headless peut s’exécuter comme Cloudflare Worker : Cloudflare construit le site web à chaque modification du dépôt Git et le diffuse dans le monde entier. WP-ImmoMakler reste la source de données et signale après chaque import que le site web doit être reconstruit. Cette page décrit ce que vous configurez pour cela dans WordPress et chez Cloudflare. Les exemples portent sur un front end Astro avec des pages générées à l’avance et des routes côté serveur pour la recherche et les formulaires, tel que l’implémente le starter Astro de 49heroes.

Ce que coûte Cloudflare

Le forfait gratuit de Workers comporte ces limites :

Forfait gratuit	Limite
Requêtes générées côté serveur (recherche, formulaires, liste de favoris, page des alertes de recherche, webhook)	100 000 par jour
Temps de calcul par requête	10 ms
Pages, images et scripts générés à l’avance	gratuits et illimités
Builds depuis Git	3 000 minutes par mois, un seul à la fois

Les pages de détail, de catégorie et de contenu sont générées lors du build et ne comptent pas comme requêtes. L’attente de WordPress ne compte pas dans le temps de calcul, seulement la génération de la page. Vous voyez les temps de calcul chez Cloudflare sous Observability du Worker. Le forfait payant commence à 5 dollars américains par mois ; les conditions actuelles figurent dans le tableau des tarifs de Cloudflare.

Prérequis

• WP-ImmoMakler à partir de la version 5.71.0 dans une édition PLUS
• Votre site WordPress est accessible depuis Internet et dispose d’un certificat valide. Un Worker n’interroge ni les adresses privées ni les pages avec un certificat auto-signé.
• Un compte Cloudflare et le dépôt Git de votre front end chez GitHub ou GitLab

Configurer dans WordPress

Dans le back end de votre site (wp-admin), sous WP-ImmoMakler → Intégrations → Headless :

1. Activer l’interface

   Activez Activer l’interface headless et enregistrez. Vérifiez que l’interface répond :

   curl -s https://www.votre-domaine.fr/wp-json/immomakler-headless/v1/site

   La réponse commence par {"api_version":. Si WordPress répond par rest_no_route, l’interface est encore désactivée ou un cache d’objets conserve les anciens réglages ; videz alors le cache.

2. Noter les identifiants

   Notez sous Identifiants d’accès la clé API et sous Secret du webhook et statut le secret du webhook. Vous enregistrerez les deux plus tard chez Cloudflare.

3. Saisir l’adresse de votre front end

   Saisissez sous Adresse de votre frontend l’adresse du Worker, par exemple https://votre-projet.votre-compte.workers.dev, plus tard votre propre domaine. Les liens de l’interface, des e-mails des demandes et des alertes de recherche pointent alors vers le front end. Vous connaîtrez l’adresse après le premier build chez Cloudflare ; vous pouvez laisser le champ vide d’ici là.

4. Saisir les adresses de proxy de confiance

   Un Worker envoie les formulaires au nom des visiteurs et n’a pas d’adresse fixe. Saisissez sous Adresses de proxy de confiance les plages d’adresses que Cloudflare publie sur cloudflare.com/ips, une par ligne en notation CIDR, par exemple 173.245.48.0/20 ou 2400:cb00::/32. Sans ces plages, la limite de requêtes par heure compte tous les visiteurs de votre front end ensemble. Plus de détails sous Formulaires via l’interface headless.

Configurer chez Cloudflare

1. Connecter le dépôt

   Dans le tableau de bord Cloudflare, ouvrez Workers & Pages → Create → Import a repository et choisissez le dépôt de votre front end. Pour un dépôt privé d’une organisation, l’application GitHub de Cloudflare doit y avoir accès ; les propriétaires de l’organisation l’autorisent chez GitHub sous Settings → GitHub Apps.

2. Configurer le build

   Choisissez un nom de projet composé de minuscules, de chiffres et de tirets ; il fait partie de l’adresse. Pour le starter Astro, la commande de build est npm run build et la commande de déploiement est npx wrangler deploy. Vous pouvez laisser les Preview builds désactivés tant que vous ne travaillez que sur la branche principale ; chaque aperçu a besoin de ses propres variables et secrets.

3. Saisir les variables de build

   Les variables sous Advanced settings → Variables ne s’appliquent qu’au build. Les valeurs écrites dans le site web lors du build vont ici ; si vous en modifiez une, un nouveau build est nécessaire. Pour le starter Astro :

   Nom	Valeur
   DEPLOY_TARGET	cloudflare
   IMMOMAKLER_API_URL	https://www.votre-domaine.fr/wp-json/immomakler-headless/v1
   PUBLIC_SITE_URL	l’adresse du Worker, après le premier build

   Ne laissez aucune ligne avec une valeur vide, sinon le bouton Deploy ne réagit pas. Le build n’a besoin de la clé API que si Exiger la clé API également pour les requêtes en lecture est activé.

4. Lancer le premier build et reprendre l’adresse

   Cliquez sur Deploy. Après le build, l’aperçu du Worker affiche son adresse, https://<nom du projet>.<compte>.workers.dev ; le sous-domaine de votre compte figure aussi dans l’aperçu sous Workers & Pages. Saisissez l’adresse comme PUBLIC_SITE_URL sous Settings → Build → Variables and secrets et dans WordPress comme Adresse de votre frontend, puis relancez le build (Retry build).

5. Enregistrer les secrets

   Sous Settings → Runtime variables and secrets, créez dans la section Production les valeurs que le Worker lit à chaque requête. Cliquez à chaque fois sur Add variable et choisissez l’entrée Secret comme Type :

   Nom	Valeur
   IMMOMAKLER_API_KEY	la clé API de l’onglet Headless
   IMMOMAKLER_WEBHOOK_SECRET	le secret du webhook du même onglet
   BUILD_HOOK_URL	l’adresse du deploy hook de la section suivante

   Les secrets prennent effet sans nouveau build. Une variable de build n’est pas disponible à l’exécution : une clé API qui ne figure que là fait défaut aux formulaires.

   Attention

   Créez aussi BUILD_HOOK_URL comme Secret, pas comme Variable. Cloudflare remplace les variables simples à chaque déploiement par celles de la configuration Wrangler du dépôt, de sorte que l’adresse manque après le prochain push. Ne suivez pas la suggestion de reprendre la variable dans la configuration Wrangler : l’adresse figurerait alors dans le dépôt, et toute personne ayant un accès en lecture pourrait lancer des builds.

Reconstruire après chaque import

WP-ImmoMakler signale les modifications au front end, et le front end lance un build chez Cloudflare :

1. Créer un deploy hook

   Chez Cloudflare, sous Settings → Builds → Deploy Hooks, créez un hook pour la branche principale et copiez son adresse. Quiconque connaît cette adresse peut lancer des builds ; traitez-la comme un mot de passe. Enregistrez-la comme secret BUILD_HOOK_URL. Si l’adresse est tombée entre de mauvaises mains, supprimez le hook, créez-en un nouveau et remplacez le secret.

2. Activer le webhook dans WordPress

   Sous Envoyer le webhook, activez l’envoi et saisissez sous Adresse du webhook l’adresse que votre front end met à disposition pour les notifications, pour le starter Astro https://<adresse du Worker>/api/revalidate/, avec la barre oblique finale. Le Délai d’attente (secondes) regroupe les modifications d’un import en un seul build.

3. Vérifier la connexion

   Cliquez sur Envoyer un message de test. Les réglages indiquent si le message a été remis ; un message de test ne déclenche aucun build. Pour vérifier toute la chaîne, modifiez et enregistrez un bien : après le délai d’attente, un nouveau build apparaît chez Cloudflare sous Deployments.

La structure du message et la manière dont votre front end vérifie la signature sont décrites dans Webhook, liens et redirection.

Astuce

Dans un Worker, le module Node node:crypto n’est disponible qu’avec le drapeau de compatibilité nodejs_compat. Avec Web Crypto, vous vérifiez la signature sans ce drapeau, aussi bien dans Node que dans Workers :

const encoder = new TextEncoder();
const key = await crypto.subtle.importKey('raw', encoder.encode(secret), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']);
const digest = new Uint8Array(await crypto.subtle.sign('HMAC', key, encoder.encode(`${timestamp}.${rawBody}`)));
const expected = 'sha256=' + Array.from(digest, (byte) => byte.toString(16).padStart(2, '0')).join('');

let difference = expected.length ^ signatureHeader.length;
for (let i = 0; i < Math.min(expected.length, signatureHeader.length); i++) {
  difference |= expected.charCodeAt(i) ^ signatureHeader.charCodeAt(i);
}
const valid = difference === 0;

Domaine propre

Enregistrez votre domaine chez Cloudflare sous Settings → Domains & Routes. Modifiez ensuite l’adresse partout : PUBLIC_SITE_URL chez Cloudflare (avec un nouveau build), Adresse de votre frontend et Adresse du webhook dans WordPress. Saisissez en outre le domaine comme domaine autorisé chez votre fournisseur de captcha, et sous Origines autorisées (Origins) si les navigateurs des visiteurs appellent directement WordPress, par exemple pour les suggestions d’adresses de la recherche par rayon.

Questions fréquentes

L’exploitation est-elle gratuite ?

Avec le forfait gratuit, vous ne payez rien tant que le site web reste dans les limites de Ce que coûte Cloudflare. Les pages générées à l’avance ne comptent pas.

Puis-je construire le site web en local et le téléverser par SFTP ?

Seulement en partie. Les pages générées à l’avance sont de simples fichiers que n’importe quel hébergement web peut servir. Mais la recherche avec filtres, les formulaires, la liste de favoris, la page des alertes de recherche et la notification après les imports nécessitent un serveur qui répond aux requêtes. Il y a deux possibilités : un forfait d’hébergement qui exécute des applications Node.js, ou un front end qui envoie la recherche et les formulaires directement depuis le navigateur vers l’interface ; les routes de formulaire acceptent ces requêtes depuis les origines autorisées. Avec un build téléversé, les nouveaux biens n’apparaissent qu’après le prochain build et le prochain téléversement.

Ai-je besoin de builds d’aperçu ?

Non. Les builds d’aperçu créent un aperçu distinct pour chaque branche sauf la branche principale. Chaque aperçu a besoin de ses propres variables et secrets et possède sa propre adresse, qui n’est pas enregistrée dans WordPress comme origine autorisée.

Où saisir quelle variable ?

Les valeurs écrites dans le site web lors du build (DEPLOY_TARGET, IMMOMAKLER_API_URL, PUBLIC_SITE_URL) sont des variables de build : lors de la création sous Advanced settings → Variables, ensuite sous Settings → Build → Variables and secrets. Les valeurs que le Worker lit à chaque requête (IMMOMAKLER_API_KEY, IMMOMAKLER_WEBHOOK_SECRET, BUILD_HOOK_URL) sont créées, une fois le projet créé, comme secrets sous Settings → Runtime variables and secrets.

Comment connaître l’adresse du Worker ?

Elle se compose du nom du projet et du sous-domaine workers.dev de votre compte. Le sous-domaine figure dans l’aperçu sous Workers & Pages, l’adresse complète dans l’aperçu du Worker après le premier build.

Dépannage

Ce que vous voyez	Cause	Solution
Le bouton Deploy ne réagit pas	une variable avec une valeur vide ou un champ invalide	supprimer les lignes vides, chercher les champs marqués en rouge
Le build s’interrompt avec GET /site failed with 404 Es wurde keine Route gefunden	l’interface est désactivée dans WordPress	Activer l’interface
Le build s’interrompt avec une erreur de certificat ou de connexion	WordPress n’est pas accessible publiquement	utiliser un site WordPress accessible publiquement avec un certificat valide
Les formulaires échouent, le jeton anti-spam répond par 502, WordPress signale 403	IMMOMAKLER_API_KEY manque à l’exécution, ne figure que dans les variables de build ou diffère de la clé API de WordPress	l’enregistrer comme secret sous Runtime variables and secrets, copier la clé API actuelle
Log : « Headless webhook address redirects; followed it once »	l’Adresse du webhook n’a pas de barre oblique finale, le front end redirige ; WP-ImmoMakler suit la redirection au sein du même domaine	saisir l’adresse indiquée dans le log sous to, par exemple …/api/revalidate/
Log : « Headless webhook refused by the front end » avec le statut 301, 302, 307 ou 308	l’adresse du webhook redirige vers un autre domaine ou avec un type de redirection que WP-ImmoMakler ne suit pas	saisir l’adresse définitive
Message de test ou log : statut 503	IMMOMAKLER_WEBHOOK_SECRET manque	l’enregistrer comme secret
Message de test : statut 401	le secret diffère de celui de WordPress	copier à nouveau le secret
Les imports ne reconstruisent pas le site web	BUILD_HOOK_URL manque ou Envoyer le webhook est désactivé	configurer le deploy hook et le webhook
Les imports ne reconstruisent le site web que jusqu’au prochain push	BUILD_HOOK_URL a été créé comme Variable au lieu de Secret, le déploiement suivant l’a supprimé	le recréer comme secret
Le sélecteur de langue ou les e-mails mènent à WordPress	Adresse de votre frontend est vide	saisir l’adresse, reconstruire
Les liens canoniques pointent vers localhost	PUBLIC_SITE_URL manque	saisir la variable de build, reconstruire

Cela pourrait aussi vous intéresser

• Mode headless avec votre propre front end
• Webhook, liens et redirection
• Formulaires via l’interface headless
• Référence de l’API de l’interface headless