Nouveautés

Lorsqu'une cible protégée par Cloudflare renvoyait une véritable page de blocage géographique (451) une fois le défi réussi, le produit Browser la signalait comme un 200 car l'observateur codait en dur le statut validé. L'observateur lit désormais le Document réel après validation, de sorte qu'un 200 reste 200, un 451 remonte comme 451, et Auto rejette le contenu erroné et continue de chercher une sortie qui correspond véritablement à vos règles validate.

Le raccourci Cmd+K (Ctrl+K) ouvre désormais la palette de commandes et la modale de recherche, quelle que soit la disposition du clavier. Nous faisions correspondre le caractère saisi (к sur une disposition cyrillique), les utilisateurs d'une disposition non latine n'obtenaient donc aucun résultat. Maintenant, nous évaluons la touche physique. Corrigé sur le site principal, le blog et la documentation.

Une résolution Auto à froid peut prendre plusieurs minutes, et la requête reste désormais ouverte pendant toute la durée de son budget. Les erreurs de n'importe quelle couche sont renvoyées sous forme de JSON que votre client peut analyser.

Les sites réutilisant les cookies (bet365 était le cobaye) restaient bloqués sur la résolution coûteuse du navigateur à 15 crédits par requête au lieu de passer à la relecture bon marché à 2 crédits après la première résolution. Deux bugs : le verrou se déclenchait sur n'importe quelle erreur de transport transitoire, et une relecture réussie du navigateur ne mettait jamais à jour les cookies de session. Les deux sont corrigés. Les requêtes répétées sur un site réutilisant les cookies coûtent désormais 2 crédits après la première résolution, exactement comme la tarification l'indique.

Nous avons renforcé l'accès cross-origin pour que seul foura.ai puisse appeler l'API avec des credentials. Nous avons également renforcé un filtre d'entrée sur l'endpoint de métriques et supprimé un secret de fallback réservé au développement. Les intégrations existantes ne changent pas.

Si vous avez défini validate.status.accept sur une requête, le moteur traite un code non-200 accepté comme un véritable succès. L'activité les marquait encore comme des échecs, ce qui faussait vos statistiques d'utilisation. Les résultats suivent désormais votre verdict de validation, donc un 403 que vous avez accepté apparaît comme un succès, et non comme un App Fail.

Si vous scrappiez des pages en cyrillique, chinois, japonais ou d'autres pages non-UTF-8 via Single, le corps de la réponse s'affichait sous forme de mojibake. Nous forcions le décodage de chaque response en UTF-8 avant que vous ne puissiez voir les octets bruts. Désormais, nous lisons le charset depuis la response (Content-Type, puis <meta charset>, puis repli sur UTF-8) et le décodons correctement. Merci à Alexandar Kanchev (Sensika) pour avoir signalé ce problème.

Certains proxies en circulation ne transfèrent pas réellement votre request. Ils la renvoient en écho sous forme de dump de serveur en texte brut et tentent d'en extraire le contenu. Nous détectons désormais ce pattern avant que la response n'atteigne votre code, ainsi Single, Browser et Proxy Finder renvoient tous un échec explicite (ou un retry) au lieu de données inutilisables.

Nous avons corrigé un ralentissement qui mettait en attente les proxies nouvellement découverts avant leur validation. Proxy Finder les vérifie désormais immédiatement, ce qui maintient le pool plus à jour avec davantage de proxies actifs et fonctionnels en rotation.

Playground suit désormais correctement l'attribut Domain, afin que les cookies limités à l'hôte restent sur leur hôte. La vue Parsed les marque avec un badge HO, et la vue Raw correspond à ce que le serveur en amont a envoyé.

Chaque champ du Playground est désormais aligné sur le schéma : le navigateur force la méthode GET, masque la zone de texte du body, et l'onglet Raw affiche le JSON exact qui atteint l'API ainsi qu'une commande curl pour le reproduire.

Avec unblocker: true, Single et Proxy Finder transportent désormais la signature complète de l'Unblocker jusqu'à l'origine, de sorte que les systèmes anti-bot qui la vérifient laissent passer la requête.

Certains sites Cloudflare renvoient un code 200 OK mais injectent un script en arrière-plan qui génère le véritable cookie cf_clearance un instant plus tard. Auparavant, Browser renvoyait la page avant l'arrivée de ce cookie, laissant le jar vide. Désormais, Browser attend l'événement lié au cookie, vous obtenez ainsi un cookie cf_clearance propre que vous pouvez rejouer via Single ou Proxy.

Le bouton Plus anciens sur le blog vous renvoyait à la page 1. La pagination se trouve désormais sur les URL /blog/page/N/ avec une navigation numérotée, afin que vous puissiez réellement parcourir les articles plus anciens. Merci, Vladimir Petrov.

Le navigateur traite désormais chaque requête via le moteur JavaScript, afin que les défis Cloudflare et les pages riches en JS s'affichent comme prévu.