Points clés
Auparavant, une organisation n'était qu'une simple ligne qui ne pouvait contenir qu'une seule personne. C'est désormais une page que vous gérez : invitez un collègue, attribuez-lui un rôle et laissez-le créer des clés facturées à l'entreprise. Proxy Finder a également cessé de répondre "out of tries" et nomme désormais l'obstacle rencontré. Enfin, Browser a passé la semaine à s'assurer qu'il présente toujours la même empreinte à une page donnée.
Nouveautés
Des organisations réellement administrables
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, avec trois rôles disponibles. Le propriétaire détient l'abonnement sur lequel 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 quelqu'un qui n'a pas encore de compte.
Chaque membre d'une organisation peut créer des clés appartenant à celle-ci et y transférer une clé personnelle. Un développeur n'a donc plus besoin d'utiliser une clé personnelle qui lui facture 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 clairement quel forfait est débité. 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 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 ne laisse plus de place au doute
"Download maxTry limit reached" s'affichait indifféremment, que chaque sortie soit bloquée, que chaque sortie soit inactive, ou que la page réelle ait été récupérée puis rejetée par votre propre règle. Ces trois cas exigent pourtant des correctifs opposés.
Une tâche en échec 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 codes HTTP 200 renvoyés sans blocage apparent mais échouant uniquement à votre validate.data. Une phrase de résumé claire accompagne ces données.
Ce dernier indicateur est particulièrement précieux. Une règle de contenu impossible à valider ressemble en tout point à un blocage selon les métriques que nous mesurions auparavant, et aucune nouvelle tentative ne pourra jamais le résoudre. (En savoir plus sur la façon dont les règles de validation déterminent le succès.)
L'autre volet concerne le profil. Proxy Finder alternait les sorties sans jamais modifier la signature client. Ainsi, un site rejetant un profil de navigateur donné le rejetait sur chaque sortie du pool. Un refus entraîne désormais une modification du profil lors d'une tentative déjà prévue, de sorte que le nombre de requêtes et de crédits par tâche reste inchangé. Fixez profile vous-même et rien ne change. Notez que sur les cibles les plus strictes, la sortie obtenue reste plus déterminante que le profil envoyé.
Browser garantit la cohérence de ses signaux
Demander un User-Agent à Browser était auparavant pire que de ne rien demander. Trois couches avaient chacune leur propre interprétation de l'origine de la requête, de sorte qu'une même requête pouvait revendiquer Windows, un Mac et une version que le parc n'exécutait pas, tout cela en même temps. Une seule valeur désormais, définie une fois, transmise partout : au lancement, à la page, aux workers lancés par la page.
Les client hints sont dérivés de cette chaîne, donc 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 déblocage sont liés à la fois au point de sortie et au User-Agent. La question du moteur de rendu renvoie désormais la même réponse dans le document et dans un worker, un autre de ces signaux faibles qui s'accumulent.
Trois autres changements sont arrivés avec :
- L'horloge suit le point de sortie. Browser s'exécute dans le fuseau horaire du pays où se situe votre point de sortie, afin qu'une page affichant des heures locales montre ce qu'un visiteur sur place verrait. Lorsque le pays n'est pas connu, l'horloge reste inchangée.
- WebRTC reste sur le même chemin que tout le reste. Une configuration proxy couvre ce qu'un navigateur envoie sur TCP. WebRTC n'étant pas sur ce chemin, une page qui lui demande des candidats ICE obtient une réponse distincte. Browser désactive cette fonction dès qu'une requête comporte un point de sortie.
- Les URL avec ancre coûtent ce qu'elles devraient. Une URL se terminant par
#reviewsentraînait systématiquement un dépassement de délai. Elle fonctionne à nouveau à vitesse normale.
Des routes plus économiques, et un Dashboard qui compte juste
Imperva injecte son script dans les pages saines, pas uniquement sur ses pages de refus, et Auto ne pouvait pas distinguer les deux, ce qui faisait escalader inutilement 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 ; cela ne prend désormais qu'une seule tentative, 10 crédits, et environ six secondes et demie. Certains sites vous transmettent une session au sein même du refus répondant à une requête sans session, et les quatre moteurs la renvoient désormais directement avant toute escalade.
La carte des crédits dans Overview affichait l'intégralité des dépenses sous le libellé facturé. Avec la tarification au succès, 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 aussi des commandes distinctes, de 30 minutes à un an plus une plage personnalisée, remplaçant la pastille 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, afin qu'une requête envoyée avec un profil que vous n'aviez 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 plus 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 faire varier la latence globale du parc. Une cible a évolué en sens inverse et nous n'en connaissons pas encore la raison, elle fait donc l'objet d'une mesure dédiée.
Une tâche vouée à l'échec échouera de toute façon. La différence réside dans le fait de clôturer le ticket en une minute ou de passer l'après-midi à mesurer le mauvais indicateur.