Dernières mises à jour et améliorations de FourA
Imperva injecte son script dans les pages saines ainsi que dans ses pages de blocage. Auto fait désormais la distinction entre les deux, de sorte qu'un site protégé par Imperva est renvoyé sans payer pour un navigateur : une tentative, 10 crédits, environ six secondes.
Définissez userAgent sur une request de navigateur et cette chaîne exacte est envoyée dans le header, dans la page et dans ses workers. Les client hints l'accompagnent, de sorte que sec-ch-ua, la plateforme et navigator.platform correspondent tous à ce que vous avez demandé. La response renvoie la même chaîne.
Le navigateur s'exécute désormais avec le fuseau horaire du pays où se trouve votre sortie, de sorte qu'une page qui affiche les heures locales les montre de la manière dont un visiteur de ce pays les verrait. Lorsque le pays de sortie n'est pas connu, l'horloge reste inchangée.
Certains sites refusent une première requête et vous attribuent une session dans la même réponse. Single, Proxy, Auto et Browser la renvoient désormais directement sur la même sortie. Ainsi, la page arrive lors de votre premier appel au lieu de vous coûter une nouvelle tentative.
Lorsqu'un site maintient son challenge, Browser indique désormais le fournisseur, le nombre de clics effectués et si l'autorisation a été accordée, afin que vous puissiez passer immédiatement à un autre proxy. Une page débloquée renvoie defenseSolved: true sur l'appel qui l'a validée.
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.
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.
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 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.
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.
Auparavant, Browser facturait le palier de 30 crédits pour la résolution de défense uniquement lorsqu'un cookie de validation Cloudflare apparaissait. Désormais, il fait de même pour toute défense que nous reconnaissons et contournons, à commencer par SiteGround. La réponse inclut également defenses: { present, cleared }, vous permettant d'identifier le fournisseur qui faisait obstacle, même si nous ne l'avons pas encore contourné (DataDome, PerimeterX, Akamai, Incapsula et hCaptcha sont reconnus pour le moment, mais pas encore contournés).
Les réponses du navigateur renvoient désormais defenses: { present, cleared } : chaque fournisseur exécuté par la cible, et tous ceux que nous avons réellement contournés. La facturation suit la même règle. Une requête qui contourne un fournisseur (et pas seulement Cloudflare) constitue une résolution de défense. Les fournisseurs que nous identifions mais ne pouvons pas encore contourner apparaissent dans present et n'augmentent jamais le prix.
Si vous passez exitCountries et que votre forfait n'inclut pas le ciblage géographique, vous recevrez une erreur 403 indiquant le paramètre et la solution. Plus besoin de deviner quel champ de la requête a déclenché la vérification. Les forfaits qui incluent le ciblage géographique ne sont pas affectés.
