Resuelve reCAPTCHA Enterprise con Python

Instala el SDK oficial de Python:

python -m pip install https://solvethree.com/downloads/solvethree_sdk-0.1.0-py3-none-any.whl

1. 1.

   Crea el perfil del sitio

   Configura el nombre de host de destino en la consola de solvethree y asegúrate de que su perfil esté activo y disponible para tu espacio de trabajo. Enviar un nombre de host en una solicitud de resolución no crea un perfil. Consulta la configuración del perfil del sitio si aún no has configurado uno.

2. 2.

   Configura SOLVETHREE_API_KEY

   En el shell o entorno de despliegue que ejecutará el script, establece SOLVETHREE_API_KEY en la clave de API de tu espacio de trabajo. Mantenla en el servidor, no en código del navegador ni en un archivo de código fuente incluido en el control de versiones.

3. 3.

   Configura SOLVETHREE_PROXY

   Establece SOLVETHREE_PROXY en la URL del proxy que usarán la resolución y la posterior solicitud a la aplicación. El ejemplo usa un solo proxy, así que no añadas también proxyCandidates.

Guarda este ejemplo como solve.py. Sustituye accounts.example.com por el nombre de host que hayas configurado, sin esquema ni ruta, y sustituye login por la acción que usa la página de destino.

import os
from uuid import uuid4
from solvethree import Solvethree, SolvethreeError, TaskFailedError

client = Solvethree(os.environ["SOLVETHREE_API_KEY"])
request = {
    "site": "accounts.example.com",  # Use your configured hostname.
    "action": "login",              # Use the page's actual action.
    "proxy": os.environ["SOLVETHREE_PROXY"],
    "requestId": str(uuid4()),
}
try:
    result = client.solve(request, timeout=180)
except TaskFailedError as error:
    raise SystemExit(f"Task failed: {error.error_code}") from None
except SolvethreeError as error:
    # Keep these IDs so an interrupted request can be recovered.
    raise SystemExit(f"Recover request {error.request_id}, task {error.task_id}") from None

solution = result["solution"]
token = solution["token"]
user_agent = solution["userAgent"]
client_hints = solution["secChUa"]
print("Ready task:", result["id"])  # Do not print the token or proxy password.

La solicitud usa enterprise-v3 de forma predeterminada, así que no necesita un campo recaptchaType. No añadas type ni url; no son campos de las solicitudes de reCAPTCHA.

Solvethree es síncrono. client.solve crea la tarea una sola vez y después consulta su estado hasta que devuelve un resultado listo o lanza una excepción. Aquí, timeout=180 establece un límite de 180 segundos para la espera del cliente. Si la operación tiene éxito, el script extrae el token, el agente de usuario y las indicaciones de cliente sin imprimir valores confidenciales.

Continúa en el mismo script después de la resolución. Instala requests por separado, como se indica en el ejemplo. Sustituye la URL de inicio de sesión y los datos del formulario por la solicitud real de tu aplicación, incluidas las credenciales, el token CSRF y las cookies de sesión que sean necesarios.

# Continue after client.solve(). Install requests separately: pip install requests.
import requests

# This example endpoint accepts the standard reCAPTCHA form field.
# Use your application's real URL, form fields, CSRF token and session.
response = requests.post(
    "https://accounts.example.com/login",
    data={"g-recaptcha-response": solution["token"]},
    headers={
        "User-Agent": solution["userAgent"],
        "sec-ch-ua": solution["secChUa"],
    },
    proxies={"http": request["proxy"], "https": request["proxy"]},
    timeout=30,
    allow_redirects=False,
)
# Inspect the application's response to determine whether it accepted the request.
print("Application HTTP status:", response.status_code)

Este ejemplo supone que la aplicación acepta el token en g-recaptcha-response. Comprueba la solicitud real en lugar de dar por hecho ese nombre de campo. Si el formulario depende de una sesión existente, envíalo a través de esa sesión en lugar de realizar una solicitud nueva sin cookies.

Conserva los valores devueltos de userAgent y secChUa, y usa el mismo proxy proporcionado para la resolución. Cambiar de IP o sustituir la identidad de navegador por otra que no corresponda puede hacer que la solicitud falle.

Que una tarea esté lista significa que se ha generado una solución, no que la aplicación la haya aceptado. Inspecciona la respuesta de la aplicación y la sesión resultante; un estado HTTP por sí solo no confirma que se haya iniciado sesión correctamente. Si rechaza el token, comprueba la solicitud saliente antes de pagar por otra resolución: debe contener solution.token, no el ID de la tarea ni un token antiguo. Consulta el diagnóstico de un token rechazado.

El ejemplo genera un nuevo requestId cada vez que se inicia el script. Guarda ese ID y la solicitud original antes de llamar a solve si necesitas recuperar la operación tras reiniciar el proceso. Volver a ejecutar el script sin más crea una nueva solicitud lógica.

• Si una excepción incluye task_id, usa get_task para reanudar las consultas de esa tarea. No crees otra para sustituirla solo porque se haya agotado el tiempo de espera de la conexión.
• Si la creación se ha interrumpido y solo tienes request_id, vuelve a enviar exactamente la misma solicitud de tarea con ese mismo requestId. Devolverá la tarea existente; cambiar los datos de entrada de la tarea mientras reutilizas el ID genera un conflicto.
• En caso de TaskFailedError, deja de consultar esa tarea. Inspecciona sus campos errorCode y error antes de reintentarlo; otra resolución no corregirá unos datos de entrada no válidos que no hayan cambiado. Las resoluciones fallidas se reembolsan.

El SDK no reintenta automáticamente la creación de tareas. Sí respeta Retry-After ante fallos temporales de las consultas dentro del plazo de resolución. Para controlar mejor la espera y la recuperación, consulta consultas de tareas y tiempos de espera.