Nouveautés

De nombreux sites rendent leur page d'entrée accessible à tous et restreignent l'accès aux pages plus profondes. Auto récupère désormais la session fournie par cette page d'entrée et l'utilise pour demander l'URL profonde, puis vous en informe avec un indicateur warmup dans la response.

Définissez timeout_ms jusqu'à 120 secondes sur une requête de navigateur et elle s'exécutera pendant toute la durée impartie. Ainsi, une cible lente bénéficie du temps que vous avez alloué et vous pouvez lire le verdict du moteur lui-même.

Browser résout désormais le challenge de la case à cocher Cloudflare sur les requêtes simultanées vers la même page, et un clic n'est pris en compte que lorsque le challenge a réellement disparu. Trois requêtes simultanées sont validées en 5 à 9 secondes.

Playground affiche désormais la réponse de votre cible, y compris sur les sites qui définissent des cookies volumineux, et les endpoints API répondent toujours en JSON.

Les pages protégées d'eBay redirigent les visiteurs vers un défi de proof-of-work Argon2. Single le résout désormais en un seul appel et renvoie l'annonce réelle pour 2 crédits, contre environ 360 via le chemin de secours. Si vous payiez le prix fort sur eBay, c'est terminé.

Si votre cible redirigeait vers un chemin d'URL différent, Browser renvoyait 'No response received' même si la page était bien reçue. C'est corrigé, la requête suit la navigation où qu'elle aboutisse. eBay, les boutiques avec de nombreuses redirections et tout ce qui utilise un 3xx vers une page de challenge fonctionnent désormais.

Les réponses signalent désormais akamai et ebay-splashui là où elles ne signalaient rien auparavant (ou attribuaient à tort le blocage à Cloudflare). Si votre code s'appuie sur defense.vendor pour choisir une stratégie de nouvelle tentative, ces deux noms s'affichent désormais correctement.

Activity s'adapte désormais à un MacBook 14" sans défilement horizontal, et chaque colonne conserve sa valeur. Le panneau de détails est un volet à onglets (Request, Response headers, Response body), la réponse se trouve donc en haut au lieu d'être 900px plus bas. Les info-bulles suivent votre pointeur et affichent l'URL complète.

La colonne de méthode lit désormais le verbe depuis le corps de votre requête (GET, POST, PUT, etc.), au lieu d'afficher toujours POST sous prétexte que c'est ce que notre couche API a reçu. Les appels Playground enregistrent également l'IP du navigateur de la personne qui a cliqué sur Envoyer, de sorte qu'un compte partagé puisse identifier qui a exécuté quoi.

FourA MCP 0.6.0 permet à un agent de choisir le navigateur présenté par une requête. foura_single et foura_proxy acceptent browser, os, version, ou un id profile exact provenant du catalogue public sur GET /api/profiles. Ils voyagent dans la requête qui remonte déjà vers le serveur, il n'y a donc aucun appel supplémentaire. Omettez-les et la requête présente le dernier Google Chrome, exactement comme avant. Une combinaison que le catalogue ne peut pas présenter renvoie une erreur listant ce qui est disponible, afin qu'une requête ne soit jamais envoyée sous un navigateur que vous n'avez pas choisi.

Les deux outils renvoient désormais defense lorsque la cible a exécuté une vérification de bot. defense.solved: false signifie que le corps peut être une page de défi plutôt que le contenu que vous avez demandé, ce qui est le signal pour réessayer avec un navigateur différent ou escalader, au lieu d'analyser une page de blocage comme des données.

Une correction dans la même version : la description de unblocker indiquait que sa valeur par défaut était désactivée. Elle a toujours été activée, les requêtes transportaient donc déjà un ensemble complet de header de navigateur. Le schéma publié correspond désormais au comportement.

Une instance saturée répond à une vérification d'état en 3 à 10 secondes là où une instance saine prend 9 à 225 millisecondes, et les deux étaient auparavant considérées comme correctes. L'état lent est désormais indiqué comme dégradé, incluant la propre raison de l'instance, de sorte que nous voyons le problème lorsqu'il ne s'agit encore que d'un serveur lent et pas encore de votre requête échouée. Le mode automatique est également surveillé, avec des limites fixées sur la durée d'une véritable résolution complexe au lieu d'une limite générique qui se déclencherait à chaque succès.

Le paramètre profile indique au débloqueur à quel navigateur ressembler sur /api/single et /api/proxy. Passez un identifiant de profil exact (comme firefox147 ou chrome146), ou laissez browser + os + version se résoudre vers la combinaison correspondante la plus récente. GET /api/profiles renvoie le catalogue actuel (79 profils répartis sur cinq familles de navigateurs), afin que vous ne codiez pas en dur une liste qui devient obsolète. Le terrain de jeu du Dashboard expose le même sélecteur sous forme de trois listes déroulantes en cascade.

Le Playground du tableau de bord dispose désormais de trois sélecteurs en cascade pour l'OS, le navigateur et la version, extraits en direct du catalogue de profils. Sélectionnez-en deux et le troisième se limite aux résultats correspondants. Le choix d'un profil active unblocker, car l'API refuse les profils sans ce paramètre.

Un service est désormais considéré comme indisponible uniquement lorsqu'il a perdu toutes ses instances, le seul état dans lequel votre request n'a nulle part où aboutir. Les déploiements continus de routine n'apparaissent plus comme des incidents sur la page de statut.

La signature par défaut envoyée par l'unblocker correspond désormais à une version majeure actuelle, et non plus à l'ancienne version codée en dur par les scrapers. Les sites qui avaient commencé à renvoyer des pages de blocage statiques aux versions majeures plus anciennes renvoient leur vraie page sur Single et Browser. Les deux produits ont évolué ensemble, donc un rejeu cf_clearance de Browser vers Single correspond toujours octet par octet.