Protección antispam para WPForms y Forminator sin captcha
Protección antispam para WPForms y Forminator sin captcha significa que el sitio comprueba que un navegador real cargó y envió el formulario, en lugar de pedirle al remitente que lo demuestre. ReportedIP Hive hace exactamente eso con ambos plugins: el envío de un bot se rechaza como error propio del formulario, encima del formulario, no se escribe ninguna entrada, no sale ningún correo, y un remitente auténtico nunca ve un acertijo, una imagen ni un paso extra.
Ambos adaptadores forman parte del plan Business y se activan con un interruptor cada uno en la página Protección, bajo Protección de formularios. WPForms llegó con Hive 2.1.65, Forminator con la 2.1.66; están probados contra WPForms Lite 2.0 y Forminator 1.57.
Por qué un captcha es la herramienta equivocada para un formulario de contacto
Un captcha hace trabajar a la persona equivocada. El remitente, que quiere contactarte, lee letras deformadas o pulsa semáforos; el script que inunda el formulario nunca iba a resolverlo y se va a un sitio con uno más débil. Cada intento fallido te cuesta un mensaje, y nunca sabrás cuántos desistieron.
Los bots vienen en dos grupos, y un formulario tiene que manejar ambos. El primero rellena todos los campos que encuentra, incluido el que debería saltarse. El segundo nunca carga la página: publica directamente contra el Endpoint con una carga copiada de un envío real. WPForms y Forminator traen cada uno un campo honeypot para el primer grupo. El segundo pasa de largo ante un honeypot, porque nunca renderiza el marcado que lo contiene.
Cómo juzga la prueba de ejecución un envío de WPForms o Forminator
Hive planta un campo de anclaje invisible en cada formulario de ambos plugins, excluido del orden de tabulación y de los lectores de pantalla. Un pequeño script añade un segundo campo cuyo nombre es distinto en cada instalación, así que una carga grabada en un sitio no encaja en ningún otro. Al enviar, el servidor lee ambos campos y clasifica la petición en uno de cuatro veredictos:
| Veredicto | Lo que contenía el envío | Qué ocurre |
|---|---|---|
proved | Anclaje vacío, campo de prueba presente | Un navegador cargó el formulario y ejecutó su script. La entrada se guarda. |
tripped | El campo de anclaje, rellenado | Rechazado. Un campo invisible rellenado es automatización sin explicación inocente. La dirección se bloquea y se notifica en el primer intento. |
failed | Anclaje vacío, campo de prueba ausente, el sitio sabe que renderiza el campo | Rechazado. La página se descargó, el script nunca se ejecutó. La dirección no se cuenta. |
absent | Ninguno de los dos campos presente | Indulgente. Hive aún no se ha visto a sí mismo renderizar el campo en este sitio, así que no se juzga nada. |
Nada específico de la petición llega al HTML. El anclaje es el mismo en cada carga de página y el nombre aleatorio vive en el script, así que una caché de páginas puede seguir sirviendo el formulario todo el tiempo que quiera sin dejar fuera a un solo visitante. La regla detrás de los cuatro veredictos es un único método que comparten todos los formularios protegidos, así que WPForms, Forminator, el formulario de comentarios y el registro de WordPress leen la misma prueba de la misma manera.
WPForms: el anclaje va delante del botón de envío
WPForms dispara wpforms_display_submit_before dentro del elemento form, justo antes del botón de envío, tanto en la carga de página como en la ruta en segundo plano, y solo cuando el plugin renderiza un formulario propio. Hive escribe ahí el anclaje. El mensaje de confirmación se renderiza en otro lugar, así que el anclaje nunca acaba junto a un texto de agradecimiento.
El veredicto se entrega en wpforms_process, que se dispara después de que el plugin haya validado todos los campos y antes de que escriba una entrada o envíe un correo. Un rechazo colocado en ese momento en la lista de errores del procesador detiene ambas cosas. WPForms muestra esa lista encima del formulario como su propio error de cabecera, tanto al recargar la página como en la respuesta en segundo plano, así que el remitente siempre lee por qué no se envió nada. Los errores de campo van primero por construcción: el hook no se alcanza mientras algún campo sea inválido, así que un formulario incompleto no cuesta ninguna consulta.
El lado del navegador no necesita ningún hook propio. WPForms valida en el evento submit del formulario, que es el que el script de Hive ya escucha, así que el campo de prueba se rellena y el envío retenido funciona sin cambios. Solo hubo que forzar una cosa: la hoja de estilos del plugin reinicia los elementos ocultos, lo que había puesto el señuelo en la página para que un visitante lo rellenara. La regla fuera de pantalla del campo señuelo gana ahora a ese reinicio.
Forminator: el anclaje en el bloque de envío, el veredicto en la lista de errores
Forminator construye el bloque que lleva su nonce y el botón de envío mediante forminator_render_form_submit_markup, y ese bloque siempre se escribe dentro del elemento form, tanto en el renderizado de la carga de página como en el renderizado AJAX. Forminator cuelga ahí su propio honeypot por la misma razón, y Hive añade su anclaje. El filtro más amplio forminator_render_form_markup sería un error: su marcado se extiende más allá de la etiqueta de cierre del formulario, así que un campo añadido caería fuera del formulario.
El veredicto cae en forminator_custom_form_submit_errors, el segundo paso del manejador de envíos, antes de construir el objeto de entrada, antes de guardarlo y mucho antes de enviar el correo. Una lista de errores no vacía detiene ahí el manejador, y Forminator responde con la lista que el remitente lee en el formulario. No se guarda nada, no se envía nada, no se ejecuta ningún complemento. Forminator asocia cada error a un identificador de campo y muestra el mensaje junto a ese campo, así que el rechazo se adjunta al primer campo del envío. El hook se dispara una segunda vez mientras se procesan los adjuntos; un rechazo que ya está en la lista nunca se añade dos veces.
Un formulario cargado después de la página se juzga como uno en la página
Un formulario de Forminator puede cargarse en la página más tarde, y ambos plugins vuelven a renderizar un formulario tras una validación fallida. El lado del servidor está cubierto porque el anclaje viaja dentro del renderizado propio del plugin, sea cual sea la ruta que lo produjo. El lado del navegador está cubierto en el momento del envío: el script de Hive actúa sobre el evento submit, y si todavía no hay ninguna respuesta calculada en reserva, retiene el envío como máximo ocho segundos mientras obtiene una, y luego manda el formulario exactamente como lo envió el visitante. Un visitante que hace clic antes de que vuelva la tarea no es un bot, y un campo vacío lo habría rechazado.
Por qué un envío rechazado es un error y no una entrada en la carpeta de spam
Ambos plugins ofrecen una carpeta de spam. WPForms puede marcar una entrada como spam, y el filtro de spam propio de Forminator deja un envío en la carpeta de spam y, según un ajuste por formulario, muestra al remitente un mensaje de éxito. Hive no usa ninguno de los dos, a propósito. Una entrada en una carpeta de spam es un mensaje por el que se dio las gracias al remitente y que el operador nunca lee. Si el veredicto fue erróneo, la persona que te escribió cree que su mensaje llegó y espera una respuesta que nunca llega.
Un rechazo de Hive es, en cambio, el error propio del formulario: el error de cabecera que WPForms usa para su propio «form has not been submitted», la lista de errores de campo que Forminator usa para un campo obligatorio dejado vacío. El remitente ve el mensaje en el formulario, puede leer por qué y puede intentarlo de nuevo. No se escribe ninguna entrada, no sale ninguna notificación y no se muestra ninguna confirmación. Este plugin nunca pierde un mensaje sin al menos decírselo al remitente.
Qué ve un bot y qué ve un visitante
| Visitante real | Script que publica contra el Endpoint | Bot que rellena todos los campos | |
|---|---|---|---|
| Carga la página | Sí | No | Sí |
| Ejecuta el script | Sí | No | Normalmente no |
| Campo de prueba | Presente | Ausente | Ausente o incorrecto |
| Campo de anclaje | Vacío | Vacío o ausente | Rellenado |
| Paso extra para la persona | Ninguno | ||
| Resultado | Entrada guardada | Rechazado en el formulario | Rechazado, dirección bloqueada y notificada |
Lo que la comprobación no puede hacer es distinguir a una persona de una botnet que maneja un navegador real. Distingue un navegador de un script. Para la dirección detrás del navegador, Hive ejecuta una segunda comprobación independiente: la comprobación de amenazas de la comunidad rechaza un envío desde una dirección a la que el sitio negaría un inicio de sesión, en el nivel de protección que aplica la página de acceso, y el remitente sabe por qué. Esa comprobación necesita el modo Community Network; la prueba de ejecución funciona también en modo Local Shield, sin que nada salga del sitio.
Qué le cuesta a la dirección un señuelo rellenado
Rellenar un campo que nadie puede ver requiere una máquina, así que Hive no espera a un segundo y un tercer intento antes de actuar. Un envío con el anclaje rellenado va directo a la escalera de bloqueo y al informe a la comunidad, tal como el filtro de comentarios trata la misma prueba desde la 2.1.52; el informe nombra el formulario por el que llegó. Una dirección de tu lista blanca queda exenta, porque la consulta está en el despachador al que acaba llegando cada sensor, no en el contador que un sensor rápido se salta.
Un visitante cuyo navegador simplemente nunca ejecutó el script no se ve afectado por esto. Su envío se rechaza con un mensaje que explica el motivo, y su dirección nunca se cuenta, porque una prueba ausente no es evidencia de una máquina.
Activarlo en cuatro pasos
- Actualiza a Hive 2.1.66 o posterior con un plan Business. En un plan inferior, los interruptores de WPForms y Forminator siguen visibles y bloqueados, con el plan necesario escrito al lado.
- Activa el interruptor de WPForms o Forminator en la página Protección, bajo Protección de formularios. Activarlo vacía las cachés de página habituales, y durante 24 horas un envío que nunca llevó la prueba sigue aceptándose, así que una página cacheada sin el campo no puede dejar fuera a nadie. El filtro
reportedip_hive_form_adapters_graceda más margen en un sitio cuya caché dura más de un día. - Ejecuta la autocomprobación en Herramientas → Diagnóstico. La tarjeta lista lo que está activado y luego hace tres pasadas con el navegador que tienes delante: como un visitante, como el mismo visitante dos veces y como un bot. No se envía ningún formulario real, no sale ningún correo y no se guarda ninguna entrada.
- Empieza opcionalmente en modo solo informe, que registra cada veredicto y no rechaza nada. Una semana de registros muestra lo que se habría rechazado antes de que se rechace algo.
La comprobación de cálculo, incluida desde Professional y por tanto en Business, cierra el único atajo que el campo de prueba simple deja abierto: leer el nombre del campo en la página y devolverlo. El navegador obtiene una pequeña tarea de tu propio sitio y la resuelve en segundo plano; la tarea está firmada con la sal del sitio, vale diez minutos y se acepta una sola vez, y el remitente sigue sin notar nada. Necesita HTTPS; sin él, la tarea conserva su firma, su caducidad y su uso único, pero no lleva aritmética.
Qué plugins de formularios reciben la misma protección
| Formulario | Plan | Probado contra |
|---|---|---|
| Formularios de comentarios, registro y contraseña olvidada | Free | Núcleo de WordPress, WooCommerce, Multisite |
| Tus propios formularios, a través de la API de formularios | Free | Tres llamadas: field, check, passes |
| Contact Form 7 | Todos los planes | La versión publicada en wordpress.org |
| WPForms y WPForms Lite | Business | WPForms Lite 2.0, ruta de carga de página y ruta en segundo plano |
| Forminator | Business | 1.57, formularios en la página y formularios cargados después |
| Gravity Forms | Business | 3.1, incluidos los formularios de varias páginas y los enviados en segundo plano |
| Formidable Forms y Formidable Forms PRO | Business | 6.35 |
| Elementor Forms | Business | Elementor PRO 3.34, el widget de formulario solo existe ahí |
| Ultimate Member | Business | 2.13, formularios de inicio de sesión, registro y contraseña |
Cada plugin tiene su propio interruptor. La capa entera, el interruptor principal, un segundo interruptor que deja fuera el registro y el restablecimiento de contraseña, y el modo solo informe están juntos en la página Protección. REPORTEDIP_HIVE_DISABLE_FORM_PROOF en wp-config.php apaga la capa para el caso en que un visitante no pueda enviar y necesites el sitio funcionando antes de depurar.
Preguntas frecuentes
¿WPForms o Forminator siguen necesitando un captcha con Hive activado?
No contra scripts y bots. La prueba de ejecución atrapa un envío que nunca cargó el formulario y un bot que rellena el campo invisible, y la comprobación de amenazas de la comunidad rechaza una dirección que la red ya conoce. Un captcha no añade nada a eso salvo un paso que el remitente tiene que dar. Lo que ningún campo puede hacer es distinguir a una persona de una botnet que maneja un navegador real, y un captcha tampoco puede.
¿Funciona junto a Akismet, el token antispam de WPForms o el honeypot de Forminator?
Sí. Hive juzga el envío en el hook de procesamiento o de validación del propio plugin, antes de que exista una entrada. Un envío rechazado nunca llega a la lista de entradas, a la carpeta de spam ni a ninguna otra comprobación antispam. Todo lo que pasa sigue hacia las comprobaciones que ya tienes en marcha.
¿Qué pasa con un visitante que tiene JavaScript desactivado?
En los plugins de formularios, un envío sin la prueba se rechaza con un mensaje que explica el motivo, porque en un formulario de contacto no hay una cola de moderación a la que recurrir. La dirección no se cuenta ni se bloquea. Un sitio con muchos visitantes así puede ejecutar la capa en modo solo informe, o dejar apagados los interruptores de WPForms y Forminator y mantener cubiertos los formularios gratuitos.
¿La comprobación ralentiza el formulario o rompe la caché de páginas?
No. El anclaje es idéntico en cada carga de página y nada específico de la petición llega al HTML, así que una página cacheada sigue siendo válida. El script rellena un campo en el momento del envío y mide cuánto tiempo estuvo el formulario en pantalla; el punto de partida viene del navegador, nunca del marcado, así que una página cacheada no puede llevar uno caducado. La tarea de cálculo viaja en un POST que ninguna caché guarda.
¿Cumple con el RGPD?
La prueba no recoge nada sobre el visitante más allá de si dos campos ocultos estaban presentes al enviar y cuántos segundos estuvo el formulario en pantalla. Sin huella digital, sin peticiones a terceros, sin imágenes servidas desde otro dominio. En modo Local Shield nada sale del sitio. La documentación del plugin de WordPress contiene el resumen completo del tratamiento de datos.
Lecturas relacionadas
- Gravity Forms sin captcha: el adaptador para un plugin que envía sus formularios por sí mismo
- Honeypot de formulario y prueba de ejecución: los cuatro veredictos y cómo los puntúa el formulario de comentarios
- Notas de la versión Hive 2.1.66: la única regla que ahora comparten todos los formularios
Consulta la documentación del plugin de WordPress para la referencia completa de ajustes y la comparativa de planes para ver qué incluye Business. Descubre ReportedIP Hive →