Una API de resolución de reCAPTCHA es distinta de siteverify
No: el endpoint siteverify de Google no puede emitir un token de respuesta de reCAPTCHA. Valida un token proporcionado por un cliente. Las evaluaciones de Enterprise también evalúan un token existente; ninguno de los dos endpoints genera uno a partir de una clave de sitio.
En esta página
Elige la API para la tarea que necesitas
| API | Qué proporcionas | Qué recibes |
|---|---|---|
| Google siteverify | Un token de respuesta existente | Un resultado de verificación |
| Evaluaciones de Google Enterprise | Un token de respuesta existente | Una evaluación de ese token |
| Tareas de solvethree | El nombre de host, la acción y la configuración de proxy de un sitio compatible | Una tarea cuyo resultado listo contiene un token de solución |
En el flujo de reCAPTCHA v3 de Google, el SDK del cliente genera un token de respuesta y el backend del propietario del sitio lo valida con siteverify. En el flujo de Enterprise, el SDK del cliente genera el token y el backend crea una evaluación.
Si vas a añadir verificación a un sitio de tu propiedad, utiliza el flujo de Google adecuado. Si necesitas un servicio de resolución para un destino compatible, utiliza la API de tareas de solvethree. El servicio de resolución proporciona un token para que el destino lo evalúe; no sustituye la verificación del destino.
Cómo es una solicitud de resolución real
Primero, asegúrate de que el sitio de destino tenga un perfil activo disponible para tu espacio de trabajo. Enviar un nombre de host y una acción no crea uno. Consulta la configuración del perfil del sitio si aún no has cumplido este requisito.
Crea la tarea con POST /v1/tasks en la API de solvethree, utilizando Authorization: Bearer seguido de la clave de API de tu espacio de trabajo. Mantén esa clave en tu servidor.
{
"site": "accounts.example.com",
"action": "login",
"proxy": "http://user:[email protected]:8080",
"requestId": "example_login_001"
}Sustituye el nombre de host, la acción y el proxy del ejemplo por los valores de tu solicitud de destino. site es un nombre de host, no una URL completa. Las solicitudes de reCAPTCHA requieren exactamente uno de los campos proxy o proxyCandidates; no añadas type ni url. Este ejemplo utiliza el valor predeterminado de recaptchaType, enterprise-v3; la pasarela también acepta v3.
Obtén la tarea con GET /v1/tasks/:id. Sigue consultándola mientras su estado sea pending o solving. Solo ready contiene una solución utilizable. Si pasa a failed, deja de consultarla y revisa errorCode y error.
No consumas un token de Enterprise en una evaluación de prueba
Google indica en su documentación que los tokens de respuesta de Enterprise para sitios web caducan a los dos minutos y solo pueden evaluarse una vez. Solicita la resolución poco antes de la solicitud protegida. Crear una evaluación solo para comprobar si el token funciona puede consumirlo antes de que lo utilice el destino previsto.
Envía solution.token al destino previsto, no el ID de la tarea. Utiliza la identidad del navegador devuelta en userAgent y secChUa, junto con el proxy con el que se completó la resolución. Cambiar de proxy o mezclar cabeceras de navegador que no correspondan puede hacer que falle la solicitud posterior.
Una tarea en estado ready significa que hay una solución disponible, no que el destino haya aceptado tu solicitud a la aplicación. Determina si se ha aceptado a partir de la respuesta del destino, no de la creación de la tarea ni de que esté lista.
Fuentes y referencia de la API
Ejecuta tu primera tarea.
Empieza con $5 de crédito en tu espacio de trabajo.