Últimas actualizaciones y mejoras de FourA
Ahora Activity se ajusta a un MacBook de 14" sin desplazamiento horizontal, y cada columna mantiene su valor. El panel de detalles es un panel con pestañas (Request, Response headers, Response body), por lo que la respuesta está en la parte superior en lugar de 900px más abajo. Los tooltips siguen a tu puntero y muestran la URL completa.
La columna del método ahora lee el verbo del cuerpo de tu request (GET, POST, PUT, etc.), en lugar de decir siempre POST porque eso fue lo que recibió nuestra capa de API. Las llamadas de Playground también registran la IP del navegador de la persona que hizo clic en Enviar, para que una cuenta compartida pueda saber quién ejecutó qué.
FourA MCP 0.6.0 permite a un agente elegir qué navegador presenta un request. foura_single y foura_proxy aceptan browser, os, version, o un id exacto de profile del catálogo público en GET /api/profiles. Viajan dentro del request que ya va hacia el upstream, por lo que no hay ninguna llamada adicional. Si los omites, el request presenta el último Google Chrome, exactamente como antes. Una combinación que el catálogo no puede presentar se devuelve como un error que enumera lo que está disponible, por lo que un request nunca se envía como un navegador que no elegiste.
Ambas herramientas ahora devuelven defense cuando el objetivo ejecuta una verificación de bots. defense.solved: false significa que el cuerpo puede ser una página de desafío en lugar del contenido que solicitaste, lo cual es la señal para reintentar con un navegador diferente o escalar, en lugar de analizar una página de bloqueo como datos.
Una corrección en la misma versión: la descripción de unblocker decía que su valor predeterminado estaba apagado. Siempre ha estado encendido, por lo que los requests ya llevaban un conjunto completo de headers del navegador. El esquema publicado ahora coincide con el comportamiento.
Una instancia saturada responde a una comprobación de estado de 3 a 10 segundos, mientras que una sana tarda de 9 a 225 milisegundos, y antes ambas se mostraban como correctas. Ahora, las instancias lentas aparecen como degradadas e incluyen el motivo de la propia instancia, de modo que vemos el problema mientras todavía es un solo servidor lento y no tu request fallida. Auto también se monitoriza, con límites ajustados al tiempo que tarda una resolución compleja real en lugar de un límite genérico que se activaría con cada éxito.
El parámetro profile le indica al unblocker qué navegador simular en /api/single y /api/proxy. Pasa un id de perfil exacto (como firefox147 o chrome146), o deja que browser + os + version se resuelvan en la combinación coincidente más reciente. GET /api/profiles devuelve el catálogo actual (79 perfiles en cinco familias de navegadores), para que no definas estáticamente en tu código una lista que se vuelva obsoleta. El entorno de pruebas del Dashboard expone el mismo selector como tres listas desplegables en cascada.
El Playground del Dashboard ahora tiene tres selectores en cascada para SO, navegador y versión, obtenidos en vivo del catálogo de perfiles. Elige dos cualquiera y el tercero se restringe a las opciones que realmente se resuelven. Seleccionar un perfil activa unblocker, porque la API rechaza los perfiles que no lo tienen.
Ahora un servicio se considera caído solo cuando ha perdido todas sus instancias, el único estado en el que tu request no tiene a dónde llegar. Los rolling deploys de rutina ya no aparecen como incidentes en la página de estado.
La firma por defecto que envía el desbloqueador es ahora una versión mayor actual, no la antigua que los scrapers tenían fijada en su código. Los sitios que habían empezado a devolver páginas de bloqueo estáticas a versiones mayores más antiguas devuelven su página real en Single y Browser. Ambos productos se actualizaron al mismo tiempo, por lo que una repetición de cf_clearance desde Browser hacia Single sigue llegando byte por byte.
Cuando tu banco solicitaba 3D Secure en una mejora de plan, la request sondeaba un cambio que nunca llegaba (nadie te había pedido que te autenticaras). El flujo de cambio de plan ahora maneja el paso adicional como lo hace la suscripción inicial, para que la mejora se procese.
Si un administrador te asigna un plan personalizado, ahora aparece en Facturación / Plan como 'Tu plan personalizado: {name} ({price})' con un botón para suscribirte. Antes de esto, la asignación permanecía invisible hasta que alguien te avisaba de que existía.
Browser solía cobrar el nivel de 30 créditos por defensa resuelta solo cuando aparecía una cookie de autorización de Cloudflare. Ahora hace lo mismo para cualquier defensa que reconocemos y superamos, empezando por SiteGround. La response también incluye defenses: { present, cleared }, para que puedas saber qué proveedor se interponía incluso cuando aún no lo hemos superado (DataDome, PerimeterX, Akamai, Incapsula y hCaptcha se reconocen por ahora, pero aún no se superan).
Las responses del navegador ahora devuelven defenses: { present, cleared }: cada proveedor que ejecutó el objetivo y cada uno que realmente superamos. La facturación sigue la misma regla. Una request que supera a cualquier proveedor (no solo Cloudflare) es una resolución de defensa, y los proveedores que reconocemos pero que aún no podemos vencer aparecen en present y nunca aumentan el precio.
SiteGround aloja una gran parte de pequeñas tiendas de WordPress y WooCommerce, por lo que su Robot Challenge Screen es una clase de objetivos, no un solo sitio. Con unblocker: true, Single ahora lo resuelve en el propio proceso y devuelve la página real. Antes de esto, tenías que iniciar Browser para esa clase de objetivo, lo que significaba pagar por una sesión de navegador y la espera. La cookie de autorización se devuelve en la response, por lo que repetirlo sigue siendo económico.
El navegador ahora maneja una página de desafío que redirige antes de que se pueda leer su cuerpo, por lo que las requests a sitios protegidos vuelven con contenido en lugar de una response vacía.
SiteGround coloca un 'Robot Challenge Screen' frente a muchas tiendas pequeñas de WordPress y WooCommerce; no hay nada en lo que hacer clic, es una prueba de trabajo SHA-1. Single ahora lo resuelve en una llamada y devuelve la página real, por 2 créditos en lugar de una sesión de navegador de 30 créditos. Es la primera defensa que no es de Cloudflare que Single maneja por su cuenta.
