Registros de clientes con letras aleatorias: cómo frenarlos

En marzo de 2025 Gustavo avisó en el grupo: «vuelven los registros de clientes con nombres y letras aleatorias». Cuentas creadas por bots, con nombres como xKqLmZp, que ensucian la base de clientes y la lista del boletín. Su solución fue un override de la validación del nombre. Funcionó a medias, y el hilo deja varias lecciones sobre cómo filtrar sin echar a clientes reales.

La idea: validar el nombre con el código de PrestaShop

PrestaShop comprueba el nombre y los apellidos del cliente con Validate::isCustomerName(). Gustavo hizo un override de esa función para que, además de la validación normal, rechazara los nombres que mezclaran tres o más mayúsculas y tres o más minúsculas. Prefiere hacerlo así antes que con un script aparte porque el formulario de registro avisa al usuario de que el nombre no es válido, como con cualquier otro error.

También compartió el hilo del foro oficial donde se habla de estos registros: registros falsos con letras aleatorias.

El problema: los nombres reales también tienen mayúsculas

Enseguida le avisaron en el grupo de que eso podía ser malo para otros. Un nombre como «María José López» tiene tres mayúsculas y muchas minúsculas, y con esa regla no se podría registrar. Otro compañero añadió que hay mucha gente que lo escribe todo en mayúsculas.

Gustavo ajustó la regla y, una semana después, contó que el bot había cambiado: ahora generaba nombres con solo dos mayúsculas o dos minúsculas juntas. De cientos de registros había bajado a unos pocos al día, pero no a cero. Su conclusión fue honesta: si el bot genera nombres que parecen reales, no hay validación del nombre que lo pare.

Una regla más precisa

Lo que delata a estos bots no es cuántas mayúsculas hay, sino dónde están: mayúsculas en mitad de una palabra, varias veces. Esta variante rechaza una palabra que pasa dos veces de minúscula a mayúscula, y deja pasar «María José López», «McDonald» o un nombre escrito todo en mayúsculas:

<?php
// override/classes/Validate.php
class Validate extends ValidateCore
{
    public static function isCustomerName($name)
    {
        // Una palabra que pasa dos veces de minúscula a mayúscula: xKqLm, aBcDeF
        if (preg_match('/\p{Ll}\p{Lu}\p{L}*\p{Ll}\p{Lu}/u', (string) $name)) {
            return false;
        }

        return parent::isCustomerName($name);
    }
}

• Después de crear el fichero, borra class_index.php de la carpeta de caché (var/cache/prod) para que PrestaShop cargue el override.
• Al final llama a la función original, así que todas las comprobaciones de PrestaShop siguen activas.
• Prueba el registro con nombres reales de tus clientes antes de dejarlo: compuestos, con tildes, con apóstrofo. Algún apellido con dos mayúsculas internas se quedaría fuera.

Otras capas que se propusieron

• Un campo que solo añaden los humanos. Otro compañero compartió un script que, al primer movimiento de ratón, tecla o clic, añade un campo oculto al formulario de registro. Un bot que envía el formulario sin interactuar no lo lleva. Ojo: el script solo crea el campo; hace falta una comprobación en el servidor, con un override o un módulo, que rechace el registro cuando falta.
• Un captcha interactivo, de los de elegir figuras. Gustavo recordaba que, cuando el captcha falla, no quedan muchas más opciones.
• Ninguna web está protegida al cien por cien, recordó otro miembro del grupo. Se trata de subirle el coste al bot.

Si ya tienes la base llena de cuentas falsas

Otro miembro del grupo borró más de 2.300 fichas de clientes falsos y vio que seguían apareciendo en la lista del boletín. Es normal: las altas en el boletín de quien no tiene cuenta no están en la tabla de clientes, sino en la del módulo de suscripción (ps_emailsubscription). Hay que limpiarlas también y, antes de nada, hacer una copia de la base de datos.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación