Points clés
Auparavant, une organisation n'était qu'une simple ligne ne pouvant contenir qu'une seule personne. C'est désormais une page que vous gérez : invitez un collègue, attribuez-lui un rôle, laissez-le créer des clés facturées à l'entreprise. De son côté, Proxy Finder ne se contente plus de répondre « tentatives épuisées » et identifie précisément l'obstacle rencontré. Enfin, Browser s'assure désormais de présenter deux fois la même configuration à une page.
Nouveautés
Des organisations réellement opérationnelles
Ajouter un collègue nécessitait auparavant de nous envoyer un e-mail, ce qui poussait les équipes à souscrire deux abonnements distincts.
Votre organisation dispose désormais de sa propre page dans le Dashboard, structurée autour de trois rôles. Le propriétaire porte l'abonnement auquel les clés sont facturées ; il n'y en a donc qu'un seul et la propriété se transmet par transfert. Les administrateurs gèrent l'utilisation, la facturation et les membres. Les membres utilisent le service. Les invitations sont envoyées par e-mail et fonctionnent même pour une personne qui n'a pas encore de compte.
Chaque membre d'une organisation peut créer des clés qui lui sont rattachées ou y transférer une clé personnelle, évitant ainsi à un développeur d'utiliser une clé personnelle qui lui facturerait le travail de l'entreprise. L'utilisation d'une clé d'organisation est facturée sur le forfait du propriétaire, et chaque confirmation indique quel forfait prend en charge le coût. Tout membre peut renommer une clé ; la régénération, la désactivation et la suppression restent réservées aux propriétaires et aux administrateurs, car ces actions interrompent immédiatement l'accès pour tous les collègues qui l'utilisent.
Un filtre Propriétaire s'applique sur Overview, Detailed Metrics, Recent Activity et votre liste de clés. Usage & Limits ainsi que Billing restent personnels, un membre n'ayant pas à consulter le quota du propriétaire.
Proxy Finder cesse les approximations
L'erreur « Download maxTry limit reached » s'affichait de façon identique, que chaque point de sortie ait été bloqué, qu'il soit indisponible ou que nous ayons récupéré la page authentique avant que votre propre règle ne la rejette. Ces trois situations exigent des corrections totalement différentes.
Une tâche échouée inclut désormais attemptReport : le nombre de sorties sans réponse, le nombre de refus par un système de défense identifié ainsi que les fournisseurs concernés, le nombre de rejets par votre validate.status et le nombre de retours HTTP 200 sans mécanisme de défense visible ayant uniquement échoué à votre validate.data. Une phrase récapitulative claire accompagne ces données.
Ce dernier indicateur est particulièrement précieux. Une règle sur le contenu qui ne peut pas matcher ressemble exactement à un blocage sous tous les angles que nous mesurions auparavant, et aucune nouvelle tentative ne pourra le résoudre. (En savoir plus sur la façon dont les règles de validation déterminent le succès.)
La seconde partie concerne le profil. Proxy Finder assurait la rotation des sorties mais jamais de la signature client ; un site rejetant un profil de navigateur le rejetait donc sur chaque sortie du pool. Désormais, un refus entraîne la modification du profil lors d'une tentative déjà prévue, sans modifier le nombre de requêtes ni les crédits par tâche. Fixez profile vous-même et rien ne changera. Sur les cibles les plus exigeantes, retenez que le point de sortie obtenu reste plus déterminant que le profil envoyé.
Browser gagne en cohérence
Demander un User-Agent à Browser était auparavant pire que de ne rien demander. Trois couches avaient chacune leur propre idée de l'identité de la requête, de sorte qu'une même requête pouvait revendiquer Windows, un Mac et une version que le parc n'utilisait pas, tout cela à la fois. Désormais, une seule valeur est définie une fois pour toutes et transmise partout : au lancement, à la page et aux workers démarrés par la page.
Les client hints sont dérivés de cette chaîne, afin que sec-ch-ua, la plateforme et navigator.platform concordent avec elle. La réponse renvoie la chaîne que nous avons réellement envoyée, ce qui est crucial car les cookies de clearance sont liés conjointement à la sortie et au User-Agent. La vérification du renderer répond également de la même manière dans le document et dans un worker désormais, un élément de plus parmi les signaux faibles qui s'accumulent.
Trois autres améliorations sont arrivées avec celle-ci :
- L'horloge suit la sortie. Browser s'exécute dans le fuseau horaire du pays où se trouve votre sortie, de sorte qu'une page affichant des heures locales présente ce qu'un visiteur sur place verrait. Lorsque le pays n'est pas connu, l'horloge reste inchangée.
- WebRTC emprunte le même chemin que tout le reste. Une configuration de proxy couvre ce qu'un navigateur envoie via TCP. WebRTC n'étant pas sur ce chemin, une page lui demandant des candidats ICE obtient une réponse distincte. Browser désactive ce comportement dès qu'une requête comporte une sortie.
- Les URL avec ancre coûtent ce qu'elles devraient. Une URL se terminant par
#reviewsdéclenchait auparavant un timeout systématique. Elle a retrouvé sa vitesse normale.
Des routes plus économiques, et un Dashboard qui compte juste
Imperva injecte son script dans les pages saines, pas uniquement dans ses pages de blocage, et Auto ne parvenait pas à faire la différence, ce qui entraînait une escalade inutile des pages saines vers un navigateur. Sur un site de location de voitures, cela représentait 75 crédits et 27,5 secondes sur six tentatives ; c'est désormais une seule tentative, 10 crédits et environ six secondes et demie. Certains sites vous transmettent une session au sein même du refus renvoyé à une requête sans session, et les quatre moteurs la renvoient désormais directement avant toute escalade.
La carte des crédits de l'Overview affichait tout ce qui était dépensé en le qualifiant de facturé. Avec le modèle pay-for-success, ces montants diffèrent et l'écart correspond à de l'argent réel. Les deux figurent donc sur la carte : le montant facturé en chiffre principal, le montant dépensé en dessous, par produit et au total. La carte Requests applique la même distinction. La période et le niveau de détail sont également des contrôles séparés, allant de 30 minutes à un an avec une plage personnalisée, remplaçant le bouton qui indiquait "1D" et ouvrait trente jours.
Dans le Playground, le bouton de report propose désormais le profil de la dernière réponse, de sorte qu'une requête partie avec un profil que vous n'avez pas saisi rejoue la version qui a fonctionné. Chaque paramètre est documenté dans la référence de l'API.
Sous le capot
Proxy Finder conserve davantage d'historique par hôte : 32 sorties au lieu d'une douzaine. Lors d'un test A/B en production, les résultats étaient équivalents sur les cibles faciles et meilleurs sur les cibles difficiles, où le temps médian d'accès à une page est passé de 5,5 s à 3,8 s sans impacter la latence globale de la flotte. Une cible a réagi en sens inverse sans que nous sachions encore pourquoi, elle fait donc l'objet d'une mesure dédiée.
Une tâche vouée à échouer échouera de toute façon. La différence réside dans le fait de clore le ticket en une minute ou de passer l'après-midi à mesurer la mauvaise métrique.