Scarnox · Blog

Arkose Labs FunCaptcha explicado: desafíos de verificación y resolución

Arkose Labs, que muchos desarrolladores siguen conociendo como FunCaptcha, es un proveedor de captcha que usan sitios grandes para registros, inicios de sesión y pagos. Su función más conocida es el desafío de verificación: un puzzle corto y de estilo juego, como girar un objeto o emparejar un patrón, que aparece cuando un motor de riesgo decide que el visitante necesita más comprobaciones. El soporte de Scarnox para Arkose está próximamente. Esta guía explica cómo funcionan los desafíos, por qué son más difíciles que los widgets sencillos y los enfoques generales para trabajos legítimos.

Cómo se entrega un desafío de Arkose

La página protegida carga un script de Arkose y le pasa una clave pública que identifica el sitio. El desafío en sí se sirve desde el proveedor, y el widget devuelve la respuesta del visitante en forma de token. Como con otros widgets basados en tokens, el backend del sitio verifica ese token con el proveedor antes de confiar en el resultado.

La clave pública es el identificador que buscas cuando quieres trabajar con una página, de la misma forma que una sitekey identifica un widget de PopularCaptcha o de reCAPTCHA. La guía para encontrar la sitekey del captcha explica cómo localizar estos identificadores en una página.

Cómo son los desafíos

Los desafíos de Arkose suelen ser cortos y visuales. Por ejemplo, girar una imagen hasta que quede derecha, seleccionar el elemento correspondiente dentro de un conjunto o seguir una secuencia en una escena 3D. El diseño cambia con frecuencia, y cada sitio puede usar un conjunto distinto de desafíos. El puzzle también es una señal en sí mismo: la forma en que el visitante se mueve y el tiempo que tarda pueden importar tanto como la respuesta final.

El motor de riesgo

Antes de mostrar un desafío, el proveedor puntúa la sesión. La puntuación se basa en señales del navegador, características del dispositivo, el historial de peticiones y el comportamiento en la página. Un visitante de bajo riesgo puede pasar sin desafío. Uno de riesgo más alto ve uno o varios puzzles, y uno de riesgo muy alto puede quedar bloqueado.

Como el motor de riesgo se ajusta por sitio y cambia con el tiempo, un enfoque genérico que funciona en un sitio puede fallar en otro. Esa es una de las razones por las que los desafíos de verificación son más difíciles de gestionar que los widgets sencillos.

Por qué la automatización lo activa

La automatización se marca por las mismas razones que otras comprobaciones basadas en puntuación: un navegador headless por defecto, una sesión nueva sin historial, un patrón de peticiones rápido y regular, y direcciones de red con mala reputación. Cada señal suma a la puntuación de riesgo. Después el desafío pide algo que la automatización no hace bien, como un arrastre preciso y con apariencia humana.

Enfoques legítimos

Para tus propias pruebas y para flujos de trabajo legítimos, estos enfoques reducen los desafíos innecesarios:

  1. Usa un perfil de navegador real con una configuración coherente, en lugar de una build de automatización sin funciones.
  2. Mantén las sesiones continuas para que el visitante no parezca nuevo en cada página.
  3. Regula las peticiones a un ritmo que una persona podría generar de forma razonable.
  4. Usa el entorno de pruebas del proveedor si el sitio es tuyo. Arkose y la mayoría de los grandes proveedores ofrecen una forma de probar una integración sin puntuación de riesgo real.
  5. Pide al titular del sitio una lista de permitidos, una API o una alternativa accesible si tu trabajo es legítimo y aun así te bloquean.

Estos enfoques reducen la frecuencia con la que aparece un desafío. No eliminan el derecho del proveedor a desafiar una sesión, y no deben usarse para superar la protección de inicio de sesión de cuentas que no son tuyas.

Qué hará un solver de Arkose

Un solver de Arkose basado en tokens recibiría la clave pública y la URL de la página, generaría un token válido y lo devolvería a tu código. Tu código enviaría entonces el token con el formulario antes de que caduque. La forma de la integración se parecería al flujo en vivo de PopularCaptcha, pero los detalles son distintos, y Scarnox documentará el tipo de tarea y los campos en la referencia de la API cuando el soporte esté disponible.

Scarnox no resuelve Arkose en directo hoy. El único tipo de tarea en vivo es PopularCaptcha, sin proxy. El soporte de Arkose está próximamente.

Dónde está la línea ética

Los desafíos de verificación existen para proteger las páginas de inicio de sesión, los flujos de pago y los formularios de registro frente al abuso. Usar cualquier solver contra esos flujos para iniciar sesión en cuentas que no son tuyas, para crear cuentas de spam o para comprar stock limitado antes que otros clientes queda fuera de los límites. Scarnox no admite esos usos. El trabajo legítimo sobre un sitio protegido debe empezar con el titular del sitio, y su respuesta decide qué está permitido.

Qué revisar antes de un trabajo

Antes de planificar cualquier trabajo contra un flujo protegido por Arkose, responde algunas preguntas. ¿El flujo es tuyo? Si lo es, el entorno de pruebas del proveedor y tu propia copia de staging son el lugar para construir y probar. ¿El trabajo es legítimo? Recopilar información pública de una forma que el sitio permite es legítimo; iniciar sesión en cuentas que no son tuyas o crear cuentas a gran escala no lo es. ¿El sitio ofrece una API o un feed de datos que haga innecesario el flujo en el navegador? Muchos sitios lo hacen, y es más rápido y estable que automatizar un desafío.

Luego revisa el volumen. Los desafíos de verificación responden al comportamiento a lo largo del tiempo, así que un trabajo que se ejecuta a un ritmo bajo y constante suele recibir menos desafíos que una ráfaga que se ejecuta de golpe. Planifica la programación con eso en mente y asegúrate de que el trabajo se detenga e informe cuando encuentre un desafío para el que no fue diseñado, en lugar de reintentar en bucle.

Por último, decide de antemano qué hará el trabajo cuando el desafío no se pueda completar. Un fallo limpio con una entrada en el registro es mucho mejor que una tormenta de reintentos que daña el sitio y hace que tu tráfico sea bloqueado.

Scrapea de forma responsable

Si el sitio protegido es uno que planeas scrapear, revisa primero el robots.txt y los términos de servicio. Mantén un ritmo bajo, evita los datos personales que no necesitas y busca una API antes de construir un flujo con navegador. La guía sobre si el web scraping es legal cubre las preguntas principales.

Próximos pasos