Passer au contenu principal
Version : 1.x

Cloudflare

Cloudflare protège votre site en demandant aux visiteurs de passer un contrôle de sécurité avant de les laisser accéder au site. Un navigateur passe ce contrôle sans intervention visible. L’application WCPOS n’est pas un navigateur : elle communique avec l’API REST de votre boutique. Lorsque Cloudflare répond à ces requêtes par une page de contrôle de sécurité au lieu de données, l’application ne peut pas se connecter.

Cette page explique comment reconnaître le problème et indiquer à Cloudflare de laisser passer l’application. Toutes les étapes s’adressent au propriétaire de la boutique ou à la personne qui gère le compte Cloudflare du site.

Comment le reconnaître​

  • L’écran de connexion affiche « La configuration d’hébergement de cette boutique bloque l’application » avec le code d’erreur HOST121.
  • L’application de bureau ouvre une petite fenêtre « Contrôle de sécurité pour your-store.com » lors de la connexion ou de la synchronisation.
  • Les anciennes versions signalaient « Le site ne semble pas être un site WordPress » ou « Le site a mis trop de temps à répondre » alors que le site était manifestement en ligne.
  • L’impression dans le cloud s’interrompt avec un message « un service de sécurité bloque WCPOS Cloud Print ».

Pour confirmer le problème, ouvrez un terminal et exécutez :

curl -sI https://your-store.com/wp-json/

Une boutique bloquée renvoie un état 403 et un en-tête cf-mitigated: challenge. Une boutique fonctionnelle renvoie 200 avec content-type: application/json. Si vous obtenez 404, votre site n’utilise pas de permaliens lisibles ; effectuez le même contrôle avec 'https://your-store.com/?rest_route=/'. Si WordPress se trouve dans un sous-dossier, incluez-le : https://example.com/shop/wp-json/.

L’application de bureau peut passer un contrôle ponctuel

Les versions récentes de l’application de bureau réussissent le contrôle de Cloudflare dans une petite fenêtre lorsque c’est possible. Vous pouvez ainsi continuer à travailler, mais l’autorisation accordée par Cloudflare expire (30 minutes par défaut) et le contrôle réapparaît. Considérez cette fenêtre comme une solution provisoire et appliquez la correction ci-dessous.

Quelle fonctionnalité Cloudflare est en cause​

La correction dépend de la fonctionnalité qui soumet l’application à un contrôle. Vérifiez les éléments suivants dans le tableau de bord Cloudflare de votre site. Cloudflare a déplacé certains menus ; leur ancien emplacement est indiqué entre parenthèses.

FonctionnalitéEmplacementPeut-elle exempter l’API ?
Bot Fight Mode (offre Free)Security → Settings → Bot traffic (ancien tableau de bord : Security → Bots)Non. Cloudflare ne permet pas aux règles Skip ou Allow de contourner cette fonctionnalité. Désactivez-la ou passez à l’offre Pro et utilisez Super Bot Fight Mode, que la règle Skip ci-dessous peut exempter.
Under Attack ModeL’interrupteur « Under Attack Mode » sur la page Overview du site, ou Security → SettingsOui. La règle Skip ci-dessous ignore Security Level, qu’Under Attack Mode renforce. Vous pouvez aussi désactiver Under Attack Mode une fois l’attaque terminée.
Super Bot Fight Mode (offre Pro et supérieure)Security → Settings → Bot traffic (ancien tableau de bord : Security → Bots)Oui, avec la règle Skip ci-dessous.
Règles WAF personnalisées ou gérées définies sur Managed ChallengeSecurity → Security rules (ancien tableau de bord : Security → WAF)Oui, avec la règle Skip ci-dessous, placée avant toute règle personnalisée qui déclenche un contrôle. Les règles gérées s’exécutent toujours après les règles personnalisées ; leur ordre n’a donc pas d’importance.

L’extension officielle Cloudflare pour WordPress peut activer ou désactiver Under Attack Mode et le WAF, mais elle ne peut pas créer de règles Skip. Celles-ci se configurent dans le tableau de bord Cloudflare.

Ajouter une règle Skip pour l’API REST​

Cette correction s’applique à tous les cas sauf Bot Fight Mode. Elle indique à Cloudflare de ne pas soumettre les requêtes à l’API REST de votre boutique à un contrôle. Les vérifications de connexion et d’autorisations de WordPress continuent de protéger ces points de terminaison.

  1. Dans le tableau de bord Cloudflare, ouvrez votre site, puis Security → Security rules (ancien tableau de bord : Security → WAF → Custom rules) et choisissez Create rule → Custom rules.

  2. Nommez-la WCPOS REST API.

  3. Sous When incoming requests match, choisissez Edit expression, puis collez :

    (starts_with(http.request.uri.path, "/wp-json/")) or (http.request.uri.path eq "/" and (starts_with(http.request.uri.query, "rest_route=") or http.request.uri.query contains "&rest_route="))

    La deuxième partie correspond à l’adresse de secours de WordPress, /?rest_route=/..., et uniquement à la racine du site. Ainsi, une chaîne rest_route= intégrée à la chaîne de requête d’une autre page ne désactive pas la protection de cette page. Si WordPress se trouve dans un sous-dossier, par exemple https://example.com/shop, utilisez /shop/wp-json/ et /shop/ à la place de /wp-json/ et de /.

  4. Sous Then take action, choisissez Skip.

  5. Cochez All remaining custom rules. Dans la liste des éléments à ignorer, cochez All Super Bot Fight Mode rules et Security Level. Cochez All managed rules uniquement si une règle gérée est à l’origine du contrôle, et ne modifiez aucune entrée marquée « (Previous version) ».

  6. Déployez la règle. Si d’autres règles personnalisées déclenchent un contrôle ou bloquent des requêtes, veillez à placer celle-ci avant elles.

Relancez le contrôle curl. L’en-tête cf-mitigated devrait avoir disparu et la réponse devrait être au format JSON.

Offre Free et Bot Fight Mode

Si le contrôle curl affiche toujours un défi après l’ajout de la règle Skip et que Bot Fight Mode est activé, Bot Fight Mode en est la cause. Avec l’offre Free, la seule solution consiste à le désactiver dans Security → Settings → Bot traffic. La documentation de Cloudflare confirme qu’aucune règle ne peut le contourner. Si Bot Fight Mode est déjà désactivé, consultez Toujours bloqué ?.

Mise en cache​

Cloudflare peut également mettre en cache les réponses de l’API REST, ce qui entraîne l’affichage de produits et de commandes obsolètes dans l’application. La règle Skip ci-dessus ne modifie pas la mise en cache. Si vous utilisez le cache Cloudflare pour les pages HTML ou Automatic Platform Optimization, ajoutez une Cache Rule qui définit Bypass cache pour la même expression.

Toujours bloqué ?​

Vérifiez que la règle Skip est déployée et non enregistrée comme brouillon, et qu’aucune règle IP Access ne bloque le réseau de la caisse. D’autres services placés devant votre site fonctionnent de la même manière que Cloudflare : consultez Conflits avec les extensions pour les extensions de sécurité, et les remarques sur l’hébergement pour GoDaddy, WP Engine et d’autres hébergeurs.