ESA ha publicado una guía y un flujo demostrativo que muestran cómo añadir un CAPTCHA basado en inteligencia artificial de forma gratuita sin tocar el código fuente de las páginas existentes. La propuesta se basa en redirigir el tráfico a una página de verificación independiente y en aplicar reglas de reescritura en el servicio ESA para forzar la comprobación antes de servir la página objetivo, de modo que el proceso actúa como punto de entrada único para la validación humana.
En la demostración técnica, el sistema emplea dos recursos principales: una página de verificación denominada captcha.html y la página que se quiere proteger, identificada como medici — capital.html. El sitio de prueba indicado en la guía es https://medicicapital.top. Para que la redirección y la validación funcionen, la guía solicita copiar valores desde la consola — por ejemplo SceneId y un prefijo de identidad (identity prefix)— e incluirlos como parámetros en la URL de redirección tras la comprobación.
El flujo de acceso descrito por ESA es el siguiente: cuando un usuario solicita la página protegida, la regla de reescritura aplicada en ESA redirige automáticamente la petición a captcha.html. Allí el usuario realiza la verificación — típicamente un clic y una comprobación por IA— y el código de captcha.html vuelve a redirigir al destino original adjuntando los parámetros de verificación y una firma. ESA valida esos parámetros y, si son correctos, permite la carga del contenido protegido.
Una ventaja destacada del enfoque es que no requiere inyectar scripts de proveedores en cada página del front — end. A diferencia de la implementación común que necesita insertar código del CAPTCHA en múltiples plantillas, todo el código de verificación reside en la única página captcha.html, que se establece como página por defecto mediante la regla de reescritura. Así se evita modificar plantillas o HTML de las páginas de negocio y se centraliza la lógica de comprobación.
La guía también documenta cómo se comporta la verificación frente a accesos directos o automatizados: si se accede directamente a medici — capital.html sin los parámetros de verificación, la autenticación falla y el servidor devuelve un error 403 según la guía. Además, el contenido que pueden raspar bots sin autenticación queda limitado a la página captcha.html, mientras que la página protegida permanece inaccesible hasta completar la comprobación y presentar la firma requerida.
En cuanto a la configuración regional y los dominios, la documentación señala consideraciones explícitas por región. Cuando el parámetro region se establece en 'cn', los servidores a usar indicados son captcha — esa-open.aliyuncs.com y captcha — esa-open-b.aliyuncs.com. Si se selecciona la región sgp, la guía recomienda cambiar a los dominios equivalentes alojados en Singapur. La configuración de la regla de reescritura debe contemplar también el soporte HTTPS si el sitio lo exige.
La guía ofrece pasos operativos concretos: configurar la regla de reescritura en ESA (incluyendo HTTPS cuando proceda), reemplazar marcadores de posición en captcha.html-como SceneId, el prefijo de identidad y la URL de destino— y verificar que la firma y los parámetros se transmiten correctamente en la redirección posterior a la comprobación. Como nota práctica, la documentación sugiere que, si se desea, se puede solicitar a un asistente de IA que adapte los estilos del frontend de captcha.html para integrarlo visualmente con el sitio.
Por último, la guía subraya la razón de fondo de esta propuesta: con la proliferación de herramientas de IA que facilitan la creación de scrapers y código de scraping, la solución planteada permite a los operadores añadir una capa de verificación humana sin rehacer el front — end. El objetivo explícito es proteger tanto páginas públicas como endpoints de API frente a accesos automatizados y abuso, y la función se presenta como gratuita en ESA.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
