Points forts
La sélection du profil de navigateur est désormais un paramètre modifiable par request. Indiquez le navigateur et l'OS souhaités, et l'empreinte ainsi que les headers décriront la même chose. Single a appris à contourner deux défenses supplémentaires cette semaine (SG-Captcha de SiteGround et le défi Argon2 d'eBay) sans lancer Browser. De plus, la vue Activity du Dashboard enregistre désormais ce que vous avez demandé, et non la mécanique sous-jacente.
Nouveautés
Choisissez votre profil de navigateur par request
Jusqu'à présent, unblocker: true sélectionnait une seule signature (notre valeur par défaut du moment) et c'était tout. Vous pouvez maintenant en désigner une :
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
ou demandez une combinaison de navigateur et d'OS :
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
L'API rejette les combinaisons inconnues par nom et liste ce qui EST disponible, de sorte qu'une faute de frappe ne puisse pas silencieusement envoyer une signature que vous n'avez jamais demandée.
Le catalogue complet se trouve à GET /api/profiles. Il est public (aucune clé requise), car c'est une liste de capacités, pas un secret. À l'heure actuelle, il y a 79 préréglages sur Chrome, Firefox, Edge, Safari et Tor, sur Windows, macOS, Android et iOS. Le Playground lit depuis la même liste, le menu déroulant affiche donc toujours exactement ce que votre code peut demander.
Pourquoi c'est important: si votre cible profile les requêtes par OS, ou si votre équipe fait de l'A/B testing pour savoir quelle stack passe un mur particulier, vous gardez maintenant cette variable stable pendant que tout le reste change.
Single passe SG-Captcha et le proof-of-work d'eBay
Deux défenses qui forçaient un rebond via Browser passent maintenant sur Single. eBay utilise son propre challenge de proof-of-work (un puzzle Argon2) et SiteGround protège une partie du web en hébergement mutualisé avec SG-Captcha. Les deux se résolvent sans rendu, ce qui signifie que la réponse revient sous la forme d'une seule requête HTTP et est facturée en conséquence.
Le signal de défense dans les réponses a également évolué. Les réponses Browser transportent désormais defenses: { present, cleared }, vous pouvez donc voir quel fournisseur se trouvait devant la page et si nous avons réussi à passer. La facturation suit la même règle: tout fournisseur que nous passons est attribué, quelle que soit sa marque. Cloudflare était la seule résolution payante avant cette fenêtre. Akamai Bot Manager, SG-Captcha et le challenge d'eBay se trouvent désormais à ses côtés.
Vue Activity reconstruite dans le Dashboard
Deux colonnes dans la liste Activity du Dashboard affichaient la mauvaise information. La méthode HTTP affichait toujours POST sur chaque ligne (tous nos endpoints sont POST, la colonne était donc une constante qui ne vous disait rien). Et l'IP client sur les appels Playground enregistrait d'où le Playground appelait, pas la personne qui cliquait sur Run.
Les deux sont corrigés. La colonne de la méthode affiche désormais le verbe que vous avez envoyé dans le corps de la requête. L'IP client sur les lignes Playground affiche maintenant l'IP du navigateur de l'utilisateur connecté, transportée dans un token Playground signé pour qu'un client API ne puisse pas la falsifier.
Le reste de la vue a été reconstruit pendant que nous y étions. Le tableau tient sur un ordinateur portable sans masquer de colonnes, la colonne produit se replie dans la ligne de requête, et le panneau de détails a gagné des onglets pour que la requête, la réponse et le résumé de défense aient chacun leur propre défilement.
Facturation: 3D Secure lors d'un changement de forfait
Si l'émetteur de votre carte exigeait une confirmation 3DS pour un changement de forfait (et pas seulement lors de l'abonnement initial), cette étape ne se déclenchait pas et le changement était silencieusement annulé. Elle se déclenche maintenant. Si vous avez essayé de changer de forfait le mois dernier et que rien ne semblait s'être passé, c'est la raison.
Sous le capot
Le Playground refuse de construire un en-tête de réponse à partir des données d'un site récupéré (un type de bug d'injection d'en-tête que nous avons corrigé très tôt). Un endpoint de facturation sur le Dashboard vérifie que l'appelant possède la ressource avant de répondre, fermant ainsi une faille IDOR.
Le pipeline de déploiement lui-même a reçu une semaine de correctifs après qu'une panne le 6 a saturé le disque de l'hôte en pleine compilation. Chaque service refuse de compiler sans espace disque disponible, les déploiements se sérialisent au lieu de s'exécuter en concurrence, la passerelle reste en ligne quand un backend est instable, et les services se terminent réellement sur SIGTERM au lieu de bloquer jusqu'à être tués trente secondes plus tard.
Pendant longtemps, le choix de la signature de navigateur était une décision que nous prenions à votre place. Cela n'a plus à l'être.