Bloquer un domaine de messagerie dans WooCommerce : Règles de wildcard Checkout Guard

Checkout Guard 1.0.2 vous permet de bloquer un domaine d'email dans WooCommerce avec une seule règle générique. Une seule entrée comme *@example.com ou 192.168.1.* arrête désormais toutes les adresses d'un domaine ou toutes les IP d'une plage. Les propriétaires de boutiques traquant la fraude répétée peuvent arrêter de maintenir manuellement des listes de correspondance exacte.

Le changement est petit à l'écran et grand en pratique. Pas de nouvelle page de paramètres, pas de nouveaux champs, pas de migration. Les quatre mêmes champs que vous utilisez déjà acceptent un caractère supplémentaire, et ce caractère change ce qu'une seule règle peut couvrir. Ci-dessous, nous expliquons ce que fait l'astérisque et comment les plages d'IP diffèrent des modèles d'email et de nom. Nous listons également les valeurs que Checkout Guard refusera d'enregistrer, et la seule chose à vérifier avant de mettre à niveau.

Table des matières

• Bloquer un domaine d'email dans WooCommerce avec une seule règle
• Ce que fait réellement l'astérisque
• Les plages d'IP fonctionnent par segment, pas par modèle
• Les valeurs que Checkout Guard refuse d'enregistrer
• Ajouter votre première règle générique
• Génériques via l'API REST
• Une chose à vérifier avant de mettre à niveau
• Questions fréquemment posées

Bloquer un domaine d'email dans WooCommerce avec une seule règle

Jusqu'à cette version, chaque valeur dans une règle de Checkout Guard était comparée comme une chaîne de caractères exacte. La casse n'avait pas d'importance pour les noms et les e-mails, mais rien d'autre n'était flexible. Si vingt commandes arrivaient de vingt adresses du même domaine jetable domaine, vous ajoutiez vingt entrées. Puis vingt-et-une quand la prochaine adresse se présentait. Garder cette liste à jour est la moitié fastidieuse de tout plan pour empêcher les commandes frauduleuses dans WooCommerce.

C'est bien quand le problème est une personne. Ce n'est pas du tout la bonne approche quand le problème est un domaine ou un bloc réseau. C'est à cela que ressemble généralement le comportement abusif une fois qu'il ne s'agit plus d'un seul client en colère et qu'il s'agit d'un script. Les jokers permettent à une seule règle de décrire tout le schéma au lieu d'énumérer les instances. Pouvoir bloquer un domaine d'e-mail dans WooCommerce avec une seule entrée est ce qui le rend pratique pour arrêter les commandes de spam dans WooCommerce une fois que le volume augmente.

Ce que fait réellement l'astérisque

Dans les champs prénom, nom et e-mail, * représente zéro ou plusieurs caractères et peut apparaître n'importe où dans la valeur :

• *@example.com bloque toutes les adresses de ce domaine
• jo* correspond à jo, john et johnny
• sm*th correspond à smith et smyth
• *son correspond à Jackson et Wilson

La correspondance reste insensible à la casse, exactement comme avant. Elle est également ancrée aux deux extrémités, ce qui est le détail que la plupart des gens comprennent mal lorsqu'ils imaginent comment cela fonctionne. john* correspond à johnny, mais ne correspond pas à ajohn. Le modèle doit tenir compte de la valeur entière, pas seulement d'une partie de celle-ci.

Chaque caractère autre que l'astérisque est traité littéralement. Le point dans *@example.com est un vrai point, pas un jeton d'expression régulière, donc un modèle ne peut pas correspondre accidentellement à plus que ce que vous vouliez. Lorsque vous bloquez un domaine d'e-mail dans WooCommerce de cette manière, seul ce domaine est affecté.

Les noms conservent le contrat qu'ils ont toujours eu. Une entrée qui bloque sur un nom nécessite que le prénom et le nom soient remplis, et les deux doivent correspondre. Chacun d'eux peut porter son propre joker, donc john* plus smith* arrêtera Johnny Smithson et laissera Johnny Jones tranquille. Entre les types de champs, la logique reste un OU : une entrée bloque une commande lorsque les deux noms correspondent, ou que l'e-mail correspond, ou que l'IP correspond.

Les plages d'IP fonctionnent par segment, pas par modèle

Les jokers IP sont délibérément plus restrictifs que les jokers d'e-mail et de nom. Une IP joker doit être au format IPv4 segmenté : exactement quatre segments séparés par des points. Chacun est soit un nombre simple de 0 à 255, soit un seul *, avec au moins un nombre réel quelque part.

Donc 192.168.1.*, 192.168.*.1 et 192.*.*.1 sont tous valides. Ceux-ci ne le sont pas :

• *.*.*.*, car aucun segment n'est un nombre réel
• 19*.168.1.1, car un segment doit être entièrement composé de chiffres ou entièrement joker, jamais un mélange
• 1.2.3.*.5, car il s'agit de cinq segments
• 2001:db8::*, car les jokers IPv6 ne sont pas pris en charge

La notation CIDR est hors de portée pour cette version. Les adresses IPv4 et IPv6 exactes fonctionnent toujours comme avant. L'adresse IP du client est résolue via l'aide de géolocalisation de WooCommerce, qui prend déjà en compte les en-têtes de proxy et transférés courants que vous obtenez derrière un CDN.

Les valeurs que Checkout Guard refuse d'enregistrer

Une règle qui correspond à tout le monde n'est pas une règle de blocage, c'est une panne. Checkout Guard rejette deux formes directement, dans la boîte de dialogue de l'administrateur et à nouveau sur l'API REST.

Le premier est un joker nu. Si la suppression des astérisques, des espaces et des caractères séparateurs d'une valeur ne laisse rien derrière, la valeur est rejetée. Cela couvre *, **, * *, et aussi les plus sournois comme *@*, *.* et *@*.*, chacun d'eux correspondrait à chaque candidat dans son champ. Une valeur comme *@example.com survit au même test car examplecom reste, c'est donc un modèle plutôt qu'un attrape-tout.

Le second est la largeur. Une seule valeur peut utiliser au maximum cinq astérisques. Six ou plus sont rejetés lors de la sauvegarde. Il y a aussi une deuxième garde au moment de la correspondance. Si une règle plus large que cinq jokers est stockée, le moteur de correspondance l'ignore et écrit dans le journal de débogage plutôt que de compiler une expression ouverte à chaque paiement.

Les deux vérifications existent sur le serveur et sont reflétées dans la boîte de dialogue de l'administrateur afin que vous obteniez l'erreur en ligne au lieu d'après un aller-retour. Le serveur fait autorité. Si les deux divergent un jour, l'écriture échoue proprement plutôt que de stocker quelque chose de faux.

Ajouter votre première règle générique

Pour bloquer un domaine de messagerie dans WooCommerce, allez à WooCommerce → Checkout Guard et ouvrez l'onglet Entrées bloquées, puis ajoutez une entrée. La boîte de dialogue est la même que celle que vous utilisiez, avec un nouveau texte d'aide sous chaque champ :

1. Prénom et Nom affichent Utilisez * comme joker, par exemple jo* et Utilisez * comme joker, par exemple sm*th.
2. Adresse e-mail affiche Utilisez * comme joker, par exemple *@example.com.
3. Adresse IP explique la règle plus stricte : une adresse IPv4 ou IPv6 unique pour une correspondance exacte, ou un modèle de segment IPv4 avec joker tel que 192.168.1.*. Elle vous rappelle également que les adresses IP sont des données personnelles, que le considérant 30 du RGPD classe comme identifiants en ligne, stockez-les donc conformément à vos obligations de confidentialité.
4. Enregistrez l'entrée.

L'application n'a pas bougé. La règle s'applique sur la page de paiement classique avec shortcode et sur la page de paiement par bloc via l'API Store, car les deux chemins passent par le même analyseur. Un acheteur bloqué voit le message que vous avez écrit dans le paramètre Message de refus de paiement, le panier est vidé et aucun paiement n'est tenté. Si vous n'avez jamais touché à ce paramètre, le message par défaut est : « Désolé, vous n’êtes pas autorisé à passer une commande pour le moment, veuillez contacter le support. »

Ce que nous avons constaté : les propriétaires de boutiques qui tirent le meilleur parti de cet outil sont ceux qui définissent des modèles restreints et des notes larges. Bloquer *@somedisposabledomain.com est une bonne idée. Bloquer *@gmail.com parce que trois commandes frauduleuses ont utilisé Gmail, c'est ainsi que vous perdez silencieusement un mois de ventes légitimes, et rien dans le plugin ne vous en empêchera, car cette règle est techniquement valide. Les caractères génériques récompensent la précision, alors vérifiez ce qu'un modèle couvre avant de le mettre en ligne.

Génériques via l'API REST

L'API REST de Checkout Guard, sous l'espace de noms cgfw/v1, accepte également des valeurs génériques, sur les créations uniques, les mises à jour et le point de terminaison par lots. Cela est important si vous souhaitez bloquer un domaine d'e-mail dans WooCommerce à partir d'un service de notation de fraude ou d'une automatisation de helpdesk. Chaque route nécessite la capacité manage_woocommerce, et les appelants machine doivent s'authentifier avec un mot de passe d'application WordPress plutôt qu'un cookie, conformément à la documentation sur les mots de passe d'application de WordPress.

Deux comportements méritent d'être connus avant de tout configurer :

POST /check, le point de terminaison qui répond « ce client serait-il bloqué », reste strict. Un candidat à la vérification est une valeur client réelle et jamais un modèle, donc un astérisque dans n'importe quel champ renvoie un 400. Les recherches de règles vont dans l'autre sens : GET /entries?email=*@example.com trouve cette règle stockée exacte, car les recherches comparent littéralement et n'étendent jamais un caractère générique. Pour la même raison, une règle générique et une règle littérale avec des caractères identiques sont toujours deux entrées distinctes, de sorte que la déduplication ne peut pas les fusionner silencieusement.

Lors des créations par lots, un élément avec un caractère générique nu est ignoré et compté dans le total skipped de la réponse au lieu d'échouer la requête entière. Cela correspond à la façon dont les adresses IP malformées étaient déjà gérées.

Une chose à vérifier avant de mettre à niveau

Il existe un cas limite unique, et il vaut deux minutes de votre temps. Une entrée enregistrée avant cette version qui contient un astérisque littéral dans un champ de nom sera désormais lue comme un modèle plutôt que comme ce caractère. Aucune migration n'est exécutée, car deviner l'intention serait pire que le changement lui-même.

Si votre liste de blocage est courte, parcourez-la. Si elle est longue, extrayez-la de GET /entries et recherchez les astérisques. Presque personne n'a un client avec un astérisque dans son nom de famille, mais presque personne n'est pas la même chose que personne.

Les règles sans astérisque sont complètement inchangées. La comparaison pour celles-ci est octet par octet ce qu'elle était auparavant, de sorte que l'écrasante majorité des listes de blocage existantes se comportent de manière identique après la mise à jour.

Vous pouvez désormais bloquer un domaine d'e-mail dans WooCommerce avec une règle de joker, dans Checkout Guard 1.0.2. Vous hésitez encore à savoir si une liste de blocage est le bon outil pour votre situation ? Nos guides sur comment bloquer un client sur WooCommerce et ce que fait un plugin de liste de blocage WooCommerce sont le point de départ.

Questions fréquemment posées

Puis-je bloquer un domaine d'email dans WooCommerce ?

Oui. Pour bloquer un domaine d'e-mail dans WooCommerce, ajoutez une règle Checkout Guard avec la valeur d'e-mail *@example.com et toutes les adresses de ce domaine seront arrêtées lors du paiement. La correspondance n'est pas sensible à la casse et couvre les paiements d'invités ainsi que les clients connectés.

Mes règles de blocage existantes fonctionnent-elles toujours après la mise à jour ?

Oui. Toute règle ne contenant pas d'astérisque est comparée exactement comme avant. La seule exception est une règle préexistante avec un astérisque littéral dans un champ de nom, qui sera désormais traitée comme un modèle générique.

Puis-je utiliser un générique pour bloquer une plage d'adresses IP ?

Vous pouvez bloquer une plage IPv4 par segment, par exemple 192.168.1.* ou 192.*.*.1. Chacun des quatre segments doit être soit un nombre de 0 à 255, soit un astérisque unique, et au moins un segment doit être un nombre. La notation CIDR et les jokers IPv6 ne sont pas pris en charge.

Pourquoi ma règle générique a-t-elle été rejetée ?

Deux valeurs sont refusées. Un joker nu tel que *, *@* ou *.* est rejeté car il correspondrait à tous les clients. Une valeur utilisant plus de cinq astérisques est rejetée pour la même raison. Ajoutez au moins un caractère littéral et gardez le modèle sous six jokers.

Le blocage générique fonctionne-t-il sur le paiement bloqué ?

Oui. Le paiement par shortcode classique et le paiement bloqué s'exécutent tous deux via le même code de correspondance, donc une règle générique se comporte de manière identique sur l'un ou l'autre. Le client bloqué voit votre message de refus personnalisé et aucun paiement n'est tenté.

Puis-je ajouter des règles génériques à partir d'un système externe ?

Oui. L'API REST Checkout Guard accepte les valeurs de joker lors de la création, de la mise à jour et de la création par lots, authentifiées avec un mot de passe d'application par un utilisateur disposant de la capacité manage_woocommerce. Le point de terminaison POST /check est l'exception et rejette les jokers, car il teste les valeurs réelles des clients plutôt que les modèles.