Si votre site est derrière Cloudflare et qu’une règle de rate limiting est active, cette règle peut aussi s’appliquer à l’API REST de WP STAGING. Cloudflare répond alors à ces requêtes par HTTP 429 (Too Many Requests) et les fonctionnalités de WP STAGING qui dépendent de l’API REST cessent de fonctionner. La solution tient en une ligne d’exclusion dans la règle de rate limiting.
Pourquoi le rate limiting de Cloudflare casse-t-il l’API REST de WP STAGING ?
Les règles de rate limiting de Cloudflare s’évaluent sur la requête entrante, pas sur l’extension qui l’a envoyée. Une règle écrite pour l’ensemble de votre domaine, ou pour un chemin très sollicité comme /booking, compte donc aussi les requêtes internes que WP STAGING adresse à sa propre API REST.
Dès que le compteur est dépassé, Cloudflare bloque les requêtes correspondantes suivantes et renvoie HTTP 429. WP STAGING n’atteint jamais WordPress, et la fonctionnalité à l’origine de l’appel échoue ou reste bloquée.
Votre site est concerné si toutes ces conditions sont réunies :
- Le rate limiting de Cloudflare est activé sur la zone.
- Une règle de rate limiting correspond au site WordPress ou à un chemin qu’il contient, par exemple
/booking. - Cette règle n’exclut pas l’API REST de WP STAGING.
Quelles fonctionnalités de WP STAGING cessent de fonctionner ?
L’API REST de WP STAGING est utilisée par plusieurs fonctionnalités, dont :
- Les tâches en arrière-plan
- Remote Sync
- Magic Login
- La mise à jour automatique des extensions
- D’autres fonctionnalités reposant sur l’API REST
Si ces requêtes sont limitées, elles échouent avec HTTP 429 et la fonctionnalité qui les a déclenchées ne peut pas aboutir.
Comment exclure l’API REST de WP STAGING du rate limiting de Cloudflare ?
Modifiez la règle de rate limiting pour qu’elle ne corresponde plus aux requêtes vers l’API REST de WP STAGING.
Étape 1 : ouvrez vos règles de rate limiting
Dans le tableau de bord Cloudflare, sélectionnez votre compte puis votre domaine, allez dans Security et ouvrez Security rules. Vos règles de rate limiting y sont listées.
Étape 2 : modifiez la règle qui couvre votre site WordPress
Ouvrez la règle qui couvre le site WordPress ou le chemin où apparaissent les réponses 429.
Étape 3 : ajoutez l’exclusion à l’expression de la règle
Ajoutez cette condition à l’expression de correspondance de la règle :
and not http.request.uri.query contains "/wpstg/v1"Une expression complète pour une règle qui protège /booking ressemble alors à ceci :
(http.host eq "example.com" and starts_with(http.request.uri.path, "/booking")) and not http.request.uri.query contains "/wpstg/v1"Étape 4 : déployez la règle
Enregistrez et déployez. Les requêtes comme celle ci-dessous ne sont plus limitées, tandis que le reste de votre site reste protégé :
?rest_route=/wpstg/v1/check_magic_loginRemarque :
wpstg/v1fait partie de la chaîne de requête, pas du chemin de l’URL. WP STAGING appelle son API REST via la forme?rest_route=, utilisez donchttp.request.uri.queryplutôt quehttp.request.uri.pathdans l’exclusion.
FAQ
Pourquoi l’exclusion utilise-t-elle http.request.uri.query et non http.request.uri.path ?
WP STAGING construit ses URL REST sous la forme https://example.com/?rest_route=/wpstg/v1/<endpoint>. L’espace de noms wpstg/v1 se trouve donc dans la chaîne de requête. Une règle qui évalue http.request.uri.path ne le verrait jamais et l’exclusion resterait sans effet.
Cette exclusion affaiblit-elle la protection de mon site ?
Elle n’exempte que les requêtes dont la chaîne de requête contient /wpstg/v1. Toutes les autres requêtes vers votre domaine continuent d’alimenter la règle de rate limiting.
Je vois aussi des erreurs 429 sur /wp-json/wpstg/v1/. Que faire ?
Certaines configurations atteignent l’API REST via la forme en permalien. Dans ce cas, ajoutez une seconde condition pour le chemin :
and not starts_with(http.request.uri.path, "/wp-json/wpstg/v1/")Le 429 peut-il avoir une autre cause que Cloudflare ?
Oui. Les pare-feux applicatifs, le rate limiting côté hébergeur et les extensions de sécurité peuvent également renvoyer HTTP 429. Consultez les journaux de votre serveur et de vos extensions si les erreurs persistent après le déploiement de l’exclusion Cloudflare.
Comment vérifier que le correctif fonctionne ?
Relancez la fonctionnalité qui échouait, par exemple ouvrez un lien Magic Login ou démarrez un Remote Sync, puis consultez le journal Security Events de Cloudflare. Les requêtes contenant /wpstg/v1 ne devraient plus afficher d’action de blocage par rate limiting.
