Checkout Guard 1.0.2 te permite bloquear un dominio de correo electrónico en WooCommerce con una regla de comodín. Una sola entrada como *@example.com o 192.168.1.* ahora detiene todas las direcciones de un dominio o todas las IPs de un rango. Los propietarios de tiendas que persiguen el fraude repetido pueden dejar de mantener listas de coincidencias exactas a mano.
El cambio es pequeño en pantalla y grande en la práctica. Sin página de configuración nueva, sin campos nuevos, sin migración. Los mismos cuatro campos que ya utilizas aceptan un carácter adicional, y ese carácter cambia lo que puede cubrir una sola regla. A continuación, cubrimos lo que hace el asterisco y cómo los rangos de IP difieren de los patrones de correo electrónico y nombre. También enumeramos los valores que Checkout Guard se negará a guardar y la única cosa que debes comprobar antes de actualizar.
Tabla de Contenidos
- Bloquear un dominio de correo electrónico en WooCommerce con una regla
- Lo que realmente hace el asterisco
- Los rangos de IP funcionan por segmento, no por patrón
- Los valores que Checkout Guard se niega a guardar
- Añadir tu primera regla de comodín
- Comodines a través de la API REST
- Una cosa a comprobar antes de actualizar
- Preguntas Frecuentes
Bloquear un dominio de correo electrónico en WooCommerce con una regla
Hasta este lanzamiento, cada valor en una regla de Checkout Guard se comparaba como una cadena exacta. La capitalización no importaba para nombres y correos electrónicos, pero nada más era flexible. Si llegaban veinte pedidos de veinte direcciones desde el mismo dominio desechable de dominio, agregabas veinte entradas. Luego veintiuna cuando aparecía la siguiente dirección. Mantener esa lista actualizada es la mitad tediosa de cualquier plan para prevenir pedidos falsos en WooCommerce.
Eso está bien cuando el problema es una persona. Es completamente inadecuado cuando el problema es un dominio o un bloque de red. Así es como suele ser el abuso una vez que deja de ser un solo cliente enfadado y se convierte en un script. Los comodines permiten que una regla describa todo el patrón en lugar de enumerar las instancias. Poder bloquear un dominio de correo electrónico en WooCommerce con una sola entrada es lo que hace práctico detener los pedidos de spam en WooCommerce una vez que el volumen aumenta.
Lo que realmente hace el asterisco
En los campos de nombre, apellido y correo electrónico, * representa cero o más caracteres y puede aparecer en cualquier lugar del valor:
*@example.combloquea todas las direcciones de ese dominiojo*coincide conjo,johnyjohnnysm*thcoincide consmithysmyth*soncoincide conJacksonyWilson
La coincidencia sigue sin distinguir entre mayúsculas y minúsculas, exactamente como estaba. También está anclada en ambos extremos, que es el detalle que la mayoría de la gente entiende mal cuando imagina cómo funciona esto. john* coincide con johnny, pero no coincide con ajohn. El patrón tiene que tener en cuenta todo el valor, no solo una parte del mismo.
Cada carácter, excepto el asterisco, se trata literalmente. El punto en *@example.com es un punto real, no un token de expresión regular, por lo que un patrón no puede coincidir accidentalmente con más de lo que pretendías. Cuando bloqueas un dominio de correo electrónico en WooCommerce de esta manera, solo se ve afectado ese dominio.
Los nombres mantienen el contrato que siempre han tenido. Una entrada que bloquea por nombre necesita que tanto el nombre como el apellido estén completos, y ambos deben coincidir. Cada uno de ellos puede llevar su propio comodín, por lo que john* más smith* detendrá a Johnny Smithson y dejará Johnny Jones en paz. Entre los tipos de campos, la lógica sigue siendo un OR: una entrada bloquea un pedido cuando ambos nombres coinciden, o el correo electrónico coincide, o la IP coincide.
Los rangos de IP funcionan por segmento, no por patrón
Los comodines de IP son deliberadamente más restrictivos que los comodines de correo electrónico y nombre. Una IP comodín tiene que ser IPv4 en forma de segmento: exactamente cuatro segmentos separados por puntos. Cada uno es un número simple de 0 a 255 o un solo *, con al menos un número real en algún lugar.
Por lo tanto, 192.168.1.*, 192.168.*.1 y 192.*.*.1 son válidos. Estos no lo son:
*.*.*.*, porque ningún segmento es un número real19*.168.1.1, porque un segmento tiene que ser todo dígitos o todo comodín, nunca una mezcla1.2.3.*.5, porque son cinco segmentos2001:db8::*, porque los comodines IPv6 no son compatibles
La notación CIDR está fuera del alcance de esta versión. Las direcciones IPv4 e IPv6 exactas siguen funcionando como antes. La IP del cliente se resuelve a través del propio asistente de geolocalización de WooCommerce, que ya tiene en cuenta los encabezados proxy y reenviados comunes que obtienes detrás de una CDN.
Los valores que Checkout Guard se niega a guardar
Una regla que coincide con todo el mundo no es una regla de bloqueo, es una interrupción del servicio. Checkout Guard rechaza dos formas de plano, en el diálogo de administración y de nuevo en la API REST.
La primera es un comodín simple. Si al eliminar los asteriscos, los espacios en blanco y los caracteres separadores de un valor no queda nada, el valor es rechazado. Eso cubre *, **, * *, y también los más sutiles como *@*, *.* y *@*.*, cada uno de los cuales coincidiría con todos los candidatos en su campo. Un valor como *@example.com sobrevive a la misma prueba porque queda examplecom, por lo que es un patrón en lugar de una captura general.
La segunda es la amplitud. Un solo valor puede usar como máximo cinco asteriscos. Seis o más son rechazados al guardarlo. También hay una segunda protección en el momento de la coincidencia. Si una regla con más de cinco comodines se almacena de alguna manera, el comparador la omite y escribe en el registro de depuración en lugar de compilar una expresión abierta en cada pago.
Ambas comprobaciones existen en el servidor y se reflejan en el diálogo de administración para que obtengas el error en línea en lugar de después de un viaje de ida y vuelta. El servidor es la autoridad. Si las dos alguna vez se desvían, la escritura falla limpiamente en lugar de almacenar algo incorrecto.
Añadir tu primera regla de comodín
Para bloquear un dominio de correo electrónico en WooCommerce, ve a WooCommerce → Checkout Guard y abre la pestaña Entradas Bloqueadas, luego agrega una entrada. El diálogo es el mismo que has estado usando, con nuevo texto de ayuda debajo de cada campo:
- Nombre y Apellido muestran
Usa * como comodín, por ejemplo jo*yUsa * como comodín, por ejemplo sm*th. - Dirección de correo electrónico muestra
Usa * como comodín, por ejemplo *@example.com. - Dirección IP explica la regla más restrictiva: una única dirección IPv4 o IPv6 para una coincidencia exacta, o un patrón de segmento IPv4 con comodines como
192.168.1.*. También te recuerda que las direcciones IP son datos personales, que el Considerando 30 del RGPD clasifica como identificadores en línea, por lo que debes almacenarlas de acuerdo con tus obligaciones de privacidad. - Guarda la entrada.
La aplicación no se ha movido. La regla se aplica en el checkout clásico con shortcode y en el checkout de bloques a través de la Store API, porque ambas rutas pasan por el mismo comparador. Un comprador bloqueado ve el mensaje que escribió en la configuración de Mensaje de denegación de checkout, el carrito se vacía y no se intenta ningún pago. Si nunca ha tocado esa configuración, el valor predeterminado dice: “Lo sentimos, no puede realizar un pedido en este momento, póngase en contacto con soporte”.
Lo que hemos visto: los propietarios de tiendas que sacan el máximo provecho de esto son los que escriben el patrón de forma restrictiva y la nota de forma amplia. Bloquear
*@somedisposabledomain.comes una buena medida. Bloquear*@gmail.comporque tres pedidos erróneos utilizaron Gmail es la forma en que pierde silenciosamente un mes de ventas legítimas, y nada en el plugin le impedirá hacerlo, porque esa regla es técnicamente válida. Los comodines recompensan la precisión, así que compruebe lo que cubre un patrón antes de que entre en vigor.
Comodines a través de la API REST
La API REST de Checkout Guard en el espacio de nombres cgfw/v1 también acepta valores comodín, en creaciones individuales, actualizaciones y el endpoint por lotes. Eso es importante si desea bloquear un dominio de correo electrónico en WooCommerce desde un servicio de puntuación de fraude o una automatización de helpdesk. Cada ruta requiere la capacidad manage_woocommerce, y los llamadores de máquina deben autenticarse con una contraseña de aplicación de WordPress en lugar de una cookie, según la documentación de contraseñas de aplicación de WordPress.
Hay dos comportamientos que vale la pena conocer antes de configurar nada:
POST /check, el endpoint que responde “¿se bloquearía a este cliente?”, se mantiene estricto. Un candidato a verificación es un valor de cliente real y nunca un patrón, por lo que un asterisco en cualquier campo allí devuelve un 400. Las búsquedas de reglas van en la otra dirección: GET /entries?email=*@example.com encuentra esa regla exacta almacenada, porque las búsquedas comparan literalmente y nunca expanden un comodín. Por la misma razón, una regla comodín y una regla literal con caracteres idénticos son siempre dos entradas distintas, por lo que la deduplicación no puede fusionarlas silenciosamente.
En las creaciones por lotes, un elemento con un comodín simple se omite y se cuenta en el total de skipped de la respuesta en lugar de fallar toda la solicitud. Eso coincide con la forma en que ya se manejaban las IPs mal formadas.
Una cosa a comprobar antes de actualizar
Hay un único caso límite, y vale la pena dedicarle dos minutos de su tiempo. Una entrada guardada antes de esta versión que contenga un asterisco literal en un campo de nombre ahora se leerá como un patrón en lugar de como ese carácter. No se ejecuta ninguna migración, porque adivinar la intención sería peor que el cambio en sí.
Si su lista de bloqueo es corta, léala rápidamente. Si es larga, extráigala de GET /entries y busque asteriscos. Casi nadie tiene un cliente con un asterisco en su apellido, pero casi nadie no es lo mismo que nadie.
Las reglas sin asterisco no se ven afectadas en absoluto. La comparación para esas es byte a byte como era antes, por lo que la gran mayoría de las listas de bloqueo existentes se comportan de manera idéntica después de la actualización.
Ahora puedes bloquear un dominio de correo electrónico en WooCommerce con una regla de comodín, en Checkout Guard 1.0.2. ¿Sigues decidiendo si una lista de bloqueo es la herramienta adecuada para tu situación? Nuestras guías sobre cómo bloquear a un cliente en WooCommerce y qué hace un plugin de lista de bloqueo de WooCommerce son el lugar para empezar.
Preguntas Frecuentes
¿Puedo bloquear un dominio de correo electrónico en WooCommerce?
Sí. Para bloquear un dominio de correo electrónico en WooCommerce, agrega una regla de Checkout Guard con el valor de correo electrónico *@example.com y se detendrán todas las direcciones de ese dominio en el proceso de pago. La coincidencia no distingue entre mayúsculas y minúsculas y cubre tanto a los invitados como a los clientes registrados.
¿Siguen funcionando mis reglas de bloqueo existentes después de la actualización?
Sí. Cualquier regla que no contenga un asterisco se compara exactamente como antes. La única excepción es una regla preexistente con un asterisco literal en un campo de nombre, que ahora se tratará como un patrón de comodín.
¿Puedo usar un comodín para bloquear un rango de IP?
Puedes bloquear un rango de IPv4 por segmento, por ejemplo 192.168.1.* o 192.*.*.1. Cada uno de los cuatro segmentos debe ser un número del 0 al 255 o un asterisco único, y al menos un segmento debe ser un número. No se admiten la notación CIDR ni los comodines IPv6.
¿Por qué se rechazó mi regla de comodín?
Se rechazan dos valores. Se rechaza un comodín simple como *, *@* o *.* porque coincidiría con todos los clientes. Se rechaza un valor que utiliza más de cinco asteriscos por la misma razón. Agrega al menos un carácter literal y mantén el patrón por debajo de seis comodines.
¿El bloqueo con comodines funciona en el checkout de bloques?
Sí. El checkout con shortcode clásico y el checkout de bloques se ejecutan a través del mismo código de coincidencia, por lo que una regla de comodín se comporta de manera idéntica en cualquiera de ellos. El comprador bloqueado ve tu mensaje de denegación personalizado y no se intenta ningún pago.
¿Puedo añadir reglas de comodines desde un sistema externo?
Sí. La API REST de Checkout Guard acepta valores comodín en la creación, actualización y creación por lotes, autenticada con una contraseña de aplicación por un usuario con la capacidad manage_woocommerce. El endpoint POST /check es la excepción y rechaza comodines, ya que prueba valores de cliente reales en lugar de patrones.
