HOST151 : rejeu de cache partagé
Ce que cela signifie
Un cache placé devant la boutique rejoue les réponses d'API d'une personne à tout le monde.
Une couche de mise en cache sert des réponses d'API REST stockées sans vérifier qui les demande : l'application a envoyé deux sondes authentifiées différemment et a reçu les deux fois la réponse de la première sonde. Sur une boutique en production, cela signifie qu'un caissier pourrait voir les données d'un autre ; la connexion est donc bloquée jusqu'à ce que le cache exclue l'API de la boutique. Il s'agit d'un problème de la couche d'hébergement — WordPress lui-même répond toujours par utilisateur.
Avant de déclencher cette erreur, l’application réessaie chaque requête avec une clé de cache unique. Lorsque ce nouvel essai prouve que la clé contourne le cache, l’application se connecte et continue d’envoyer cette clé. Vous ne voyez donc cette erreur que si la nouvelle tentative n’a pas non plus permis d’établir une connexion sûre.
Vos données
Les données de cet appareil peuvent être à risque — n'effacez pas les données locales. Si le problème persiste, exportez les diagnostics et contactez le support WCPOS.
Dépannage
- L’application a déjà réessayé chaque requête avec une clé de cache unique, sans parvenir à établir une connexion sûre. Le cache doit donc être corrigé sur l’hôte.
- Excluez les chemins de l'API REST de la boutique (/wp-json/ et /?rest_route=) de la mise en cache des pages — sur LiteSpeed, désactivez la mise en cache REST ou ajoutez une règle no-cache ; sur WP Engine, étendez l'exclusion WooCommerce à /wp-json/wcpos ; sur Sucuri, réglez le niveau de mise en cache pour respecter Cache-Control.
- L'API de la boutique envoie déjà Cache-Control: no-store et Vary: Authorization — la couche de cache les ignore ; orientez l'hébergeur vers ces en-têtes.
- Après avoir modifié les réglages du cache, purgez le cache avant de vous reconnecter.