Dernières mises à jour et améliorations de FourA
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.
Lorsque votre banque demandait le 3D Secure lors d'une mise à niveau de forfait, la requête attendait un changement qui n'arrivait jamais (personne ne vous avait invité à vous authentifier). Le flux de modification de forfait gère désormais cette étape supplémentaire comme lors du premier abonnement, afin que la mise à niveau aboutisse.
Si un administrateur vous attribue un forfait personnalisé, il s'affiche désormais dans Facturation / Forfait sous la forme 'Votre forfait personnalisé : {name} ({price})' avec un bouton pour vous abonner. Auparavant, cette attribution restait invisible jusqu'à ce que quelqu'un vous informe de son existence.
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.
SiteGround sert de front-end à une grande partie des petites boutiques WordPress et WooCommerce, son Robot Challenge Screen est donc une classe de cibles et non un seul site. Avec unblocker: true, Single le résout désormais in-process et renvoie la page réelle. Auparavant, vous deviez lancer Browser pour cette classe de cible, ce qui signifiait payer pour une session de navigateur et attendre. Le cookie d'autorisation revient dans la response, une répétition reste donc peu coûteuse.
Le navigateur gère désormais une page de challenge qui redirige avant que son corps puisse être lu, de sorte que les requêtes vers les sites protégés reviennent avec du contenu au lieu d'une réponse vide.
SiteGround place un 'Robot Challenge Screen' devant de nombreuses petites boutiques WordPress et WooCommerce ; il n'y a rien à cliquer, il s'agit d'une preuve de travail SHA-1. Single le contourne désormais en un seul appel et renvoie la page réelle, pour 2 crédits au lieu d'une session de navigateur à 30 crédits. C'est la première protection non-Cloudflare que Single gère de manière autonome.
