Protección contra el spam de Gravity Forms sin captcha
La protección contra el spam de Gravity Forms sin captcha significa que el sitio web comprueba que un navegador real ha cargado y enviado el formulario, en lugar de pedir al visitante que lo demuestre. ReportedIP Hive hace precisamente eso para Gravity Forms: el envío de un bot se rechaza como un error de validación que aparece encima del formulario, no se registra ninguna entrada y el remitente auténtico nunca ve ningún rompecabezas, ninguna imagen ni ningún paso adicional.
El adaptador de Gravity Forms forma parte del plan Business y se activa con un botón situado en la página «Protección», en la sección «Protección de formularios». Se incluyó con la versión 2.1.63 de Hive y se ha probado con Gravity Forms 3.1.
Por qué un captcha no es la herramienta adecuada para un formulario de contacto
Un captcha le pide a la persona equivocada que haga el trabajo. El remitente, que quiere ponerse en contacto contigo, tiene que leer letras distorsionadas o hacer clic en semáforos; el script que inunda el formulario nunca iba a resolverlo y simplemente pasa a un sitio web con uno más fácil. Cada intento fallido te cuesta un mensaje, y nunca llegas a saber cuántos se han rendido.
Los bots se dividen en dos grupos, y un formulario debe gestionar ambos. El primero rellena todos los campos que encuentra, incluidos aquellos que debería omitir. El segundo ni siquiera carga la página: envía directamente la solicitud al Endpoint con una Payload copiada de un envío real. Gravity Forms incluye su propio campo «Honeypot» para el primer grupo. El segundo pasa de largo por el «Honeypot», ya que nunca muestra el código que lo contiene.
Cómo evalúa la prueba de ejecución un envío de Gravity Forms
Hive inserta un campo de anclaje invisible en cada formulario de Gravity Forms de la página, que queda excluido del orden de tabulación y de los lectores de pantalla. A continuación, un pequeño script añade un segundo campo cuyo nombre varía en cada instalación, de modo que una Payload grabada en un sitio web no sirve para ningún otro. Al enviar el formulario, el servidor lee ambos campos y clasifica la solicitud en una de estas cuatro categorías:
| Veredicto | Lo que contenía el envío | ¿Qué pasa? |
|---|---|---|
proved | Ancla vacía, campo de prueba presente | Un navegador ha visualizado el formulario y ha ejecutado su script. La entrada se ha guardado. |
tripped | El campo de anclaje, rellenado | Rechazado. Un campo invisible rellenado es una automatización sin explicación plausible, y la dirección asciende en la escala de bloques. |
failed | Ancla vacía, falta el campo de prueba; el sitio web sabe que muestra el campo | Rechazado. Se ha recuperado la página, pero el script nunca se ha ejecutado. |
absent | No se ha rellenado ninguno de los dos campos | Indulgente. Hive aún no ha comprobado que muestra el campo por sí mismo en este sitio web, por lo que no se emite ningún juicio. |
No llega nada específico de la solicitud al código HTML. El ancla es la misma cada vez que se carga la página; el nombre aleatorio se almacena en el script, por lo que la caché de la página puede seguir mostrando el formulario todo el tiempo que quiera sin que ningún visitante se quede sin acceso.
Gravity Forms envía sus formularios por sí mismo
La mayoría de los plugins de formularios envían los datos a través del evento «submit» habitual del navegador, que es donde el script de Hive rellena el campo de prueba. Gravity Forms no lo hace así: recoge y envía el formulario por su cuenta y, al hacerlo, no activa ningún evento de envío. Sí que publica un filtro de JavaScript precisamente para este momento, «gform/submission/pre_submission», el mismo que utiliza su propio captcha invisible. Hive se engancha a ese filtro, rellena el campo de verificación y devuelve el formulario.
En el servidor, el ancla se introduce a través de gform_form_tag, por lo que se sitúa dentro del elemento «form» sin buscar en el código una etiqueta de cierre, y la decisión se toma en «gform_validation», el gancho que Gravity Forms ejecuta en cada envío antes de crear una entrada.
Los formularios de varias páginas se evalúan una sola vez, en la última página
Un formulario de varias páginas envía cada página como una solicitud independiente. Solo la última página constituye un envío, por lo que solo esa se evalúa. Evaluar cada paso supondría un gasto innecesario de recursos de cálculo y de búsqueda en la comunidad. Los formularios enviados en segundo plano, el modo AJAX que utilizan la mayoría de los sitios web, se tratan de la misma manera que un formulario enviado al recargar la página, y el mensaje de rechazo se muestra encima del formulario en ambos casos.
Un formulario que se entrega fuera de plazo se vuelve a tramitar
Un formulario de Gravity Forms que se vuelve a cargar, ya sea tras una validación fallida o dentro de una ventana emergente, llega después de la primera ejecución del script. Hive detecta el evento de renderización propio del plugin y vuelve a procesar el formulario: lee el desafío, reinicia el temporizador y aplica el filtro de envío. Antes de la versión 2.1.63, dicho formulario no encontraba ninguna respuesta calculada en espera y se rechazaba por no estar comprobado; esto ya se ha corregido.
¿Por qué una presentación rechazada se considera un error de validación y no un mensaje que va a parar a la carpeta de spam?
Gravity Forms dispone de una carpeta de spam, y el adaptador podría haber archivado allí los envíos rechazados. Sin embargo, no lo hace, a propósito. Una entrada en la carpeta de spam es un mensaje por el que se ha agradecido al remitente y que el administrador 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 por parte de Hive es, en realidad, un error de validación a nivel del formulario, el mismo mecanismo que utiliza Gravity Forms para su propia regla de «debe rellenarse al menos un campo». El remitente ve el mensaje encima del formulario, puede leer el motivo y volver a intentarlo. No se registra ninguna entrada, no se envía ninguna notificación y no se muestra ninguna página de confirmación. Este plugin nunca pierde un mensaje sin, como mínimo, avisar al remitente.
Lo que ve un bot y lo que ve un visitante
| Visitante auténtico | Script que publica directamente en el Endpoint | Bot que rellena todos los campos | |
|---|---|---|---|
| Carga la página | Sí | No | Sí |
| Ejecuta el script | Sí | No | Normalmente no |
| Campo de comprobación | Presente | Ausente | Ausente o incorrecto |
| Campo de anclaje | Vacío | Vacío o falta | Relleno |
| Paso adicional para la persona | Ninguno | ||
| Resultado | Entrada guardada | Rechazado en la parte superior del formulario | Rechazado, se ha contabilizado la dirección |
Lo que la comprobación no puede hacer es distinguir entre una persona y una red de bots que controla un navegador real. Lo que sí hace es distinguir entre un navegador y un script. En cuanto a la dirección detrás del navegador, Hive realiza una segunda comprobación independiente: la comprobación de amenazas de la comunidad rechaza cualquier envío procedente de una dirección a la que el sitio web denegaría el acceso, según el nivel de protección que aplique la página de inicio de sesión, y se explica al remitente el motivo. Esa comprobación requiere el modo «Community Network»; la prueba de ejecución también funciona en el modo «Local Shield», sin que nada salga del sitio web.
Los envíos realizados a través de la API de Gravity Forms nunca se evalúan
Una importación, una fuente de Zapier o una llamada REST a través de la API de Gravity Forms no incluyen ningún campo de anclaje ni de prueba, y sin una regla que lo especifique, cada una de ellas se interpretaría como un cliente que no ha superado la comprobación. Hive consulta al gancho de validación si el envío procede de un navegador y no interviene en ningún otro caso. Desde la versión 2.6.4 de Gravity Forms, el propio gancho lo indica; en versiones anteriores del plugin, Hive realiza la consulta tal y como lo hace el propio Honeypot del plugin.
Cómo encenderlo en cuatro pasos
- Actualiza a Hive 2.1.63 o una versión posterior con un plan Business. En un plan de categoría inferior, el botón de Gravity Forms permanece visible y bloqueado, y junto a él aparece indicado el plan correspondiente.
- Activa el interruptor de Gravity Forms en la página «Protección», en la sección «Protección de formularios». Al activarlo, se borran las cachés habituales de la página y, durante 24 horas, se siguen aceptando los envíos que nunca hayan incluido la prueba, de modo que una página almacenada en caché sin ese campo no impedirá el acceso a nadie. El filtro
reportedip_hive_form_adapters_graceofrece más margen en un sitio web cuya caché dura más de un día. - Ejecuta la autocomprobación en Herramientas → Diagnóstico. La tarjeta muestra lo que está activado y, a continuación, realiza tres simulaciones con el navegador que tienes abierto: como un visitante, como el mismo visitante dos veces y como un bot. No se envía ningún formulario real, no se envía ningún correo electrónico y no se almacena ningún dato. De lo contrario, es difícil distinguir una protección invisible de la ausencia total de protección.
- Si lo deseas, puedes empezar en Report-Only Mode, que registra cada veredicto y no rechaza nada. Una semana de registros muestra lo que se habría rechazado antes de que se rechazara nada.
La comprobación de cálculo, incluida a partir de la versión Professional y, por lo tanto, también en la versión Business, elimina la única vía que deja abierta el campo de verificación simple: leer el nombre del campo de la página y volver a enviarlo. El navegador realiza un pequeño cálculo en segundo plano, cada respuesta se acepta una sola vez y el remitente sigue sin darse cuenta de nada. Requiere HTTPS; sin él, el campo de verificación simple sigue decidiendo.
¿Qué plugins de formularios cuentan con la misma protección?
| Formulario | Plan | Probado con |
|---|---|---|
| Formularios de comentarios, registro y recuperación de contraseña | Gratis | Núcleo de WordPress, WooCommerce, Multisite |
| Tus propios formularios, a través de la API de formularios | Gratis | Tres llamadas: field, check, passes |
| Contact Form 7 | Todos los planes | La versión publicada en WordPress.org |
| Gravity Forms | Business | 3.1, incluidos los formularios de varias páginas y los formularios en segundo plano |
| Formidable Forms y Formidable Forms PRO | Business | 6.35 |
| Formularios de Elementor | Business | Elementor PRO 3.34: el widget de formulario solo está disponible en esta versión |
| Ultimate Member | Business | 2.13, formularios de inicio de sesión, registro y contraseña |
Cada plugin tiene su propio interruptor. La capa completa, el interruptor principal, un segundo interruptor que excluye el registro y el restablecimiento de contraseña, y el Report-Only Mode se encuentran todos juntos en la página «Protección». REPORTEDIP_HIVE_DISABLE_FORM_PROOF en wp-config.php desactiva la capa en los casos en los que un visitante no pueda enviar datos y sea necesario que el sitio web funcione antes de proceder a la depuración.
Preguntas frecuentes
¿Sigue siendo necesario un captcha en Gravity Forms cuando Hive está activado?
No contra los scripts ni los bots. La prueba de ejecución detecta un envío en el que nunca se ha visualizado 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 aporta nada más que un paso adicional que el remitente tiene que realizar. Lo que ningún campo puede hacer es distinguir a una persona de una red de bots que utiliza un navegador real, y un captcha tampoco puede hacerlo.
¿Funciona junto con Akismet o con el «Honeypot» de Gravity Forms?
Sí. Hive evalúa el envío en el hook de validación, antes de que exista ninguna entrada. Un envío rechazado nunca llega a la lista de entradas, a la carpeta de spam ni a ningún otro plugin antispam. Todo lo que pasa este filtro pasa a las comprobaciones que ya realizas.
¿Qué le ocurre a un visitante que tiene desactivado JavaScript?
En los plugins de formularios, un envío sin la prueba se rechaza con un mensaje que explica el motivo, ya que en un formulario de contacto no hay una cola de moderación a la que recurrir. En el formulario de comentarios, el mismo caso solo requiere un paso de moderación. Un sitio web con muchos visitantes de este tipo puede ejecutar la capa en Report-Only Mode, o dejar desactivada la opción de Gravity Forms y mantener protegidos los formularios gratuitos.
¿Esta comprobación ralentiza el formulario o impide el almacenamiento en caché de las páginas?
No. El ancla es idéntica cada vez que se carga la página y no llega nada específico de la solicitud al código HTML, por lo que una página almacenada en caché sigue siendo válida. El script rellena un campo en el momento del envío y mide cuánto tiempo ha estado el formulario en pantalla; el punto de partida proviene del navegador, nunca del código de marcado, por lo que una página almacenada en caché no puede contener datos obsoletos.
¿Cumple con el RGPD?
La prueba no recopila ningún dato sobre el visitante, salvo si había dos campos ocultos en el momento del envío y cuántos segundos permaneció el formulario en pantalla. No se realiza ningún tipo de «huella digital», ni se envían solicitudes a terceros, ni se muestra ninguna imagen procedente de otro dominio. En el modo «Local Shield», no sale absolutamente nada del sitio web. La documentación del plugin de WordPress incluye el resumen completo sobre el tratamiento de datos.
Lecturas relacionadas
- Honeypot y prueba de ejecución: los cuatro veredictos y cómo los puntúa el formulario de comentarios
- Decoy Paths: una trampa diferente que avisa al escáner en su primera exploración
- Audit Event Trail, la otra funcionalidad Business que se incorporó una versión antes
Consulta la documentación del plugin de WordPress para ver la referencia completa de la configuración y la comparación de planes para saber qué incluye el plan Business. Explora ReportedIP Hive →