Points clés
La sélection du profil de navigateur est désormais un paramètre configurable par requête. Spécifiez le navigateur et l'OS souhaités, et le fingerprint ainsi que les headers s'alignent en conséquence. Single a appris cette semaine à valider deux vérifications supplémentaires (les contrôles computationnels de SiteGround et d'eBay) sans devoir lancer Browser. De plus, la vue Activity du Dashboard consigne désormais ce que vous avez demandé, et non les mécanismes internes sous-jacents.
Nouveautés
Définissez votre profil de navigateur par requête
Jusqu'à présent, unblocker: true sélectionnait une signature unique (notre configuration par défaut du moment) sans autre option. Vous pouvez désormais en spécifier 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 leur nom et liste ce qui EST disponible, de sorte qu'une faute de frappe ne puisse pas appliquer silencieusement une signature que vous n'avez jamais demandee.
Le catalogue complet est disponible sur GET /api/profiles. Il est public (aucune cle requise), car il s'agit d'une liste de capacites et non d'un secret. Au moment d'ecrire ces lignes, il existe 79 presets couvrant Chrome, Firefox, Edge, Safari et Tor, sur Windows, macOS, Android et iOS. Le Playground lit cette meme liste, le menu deroulant affiche donc toujours exactement ce que votre code peut demander.
Pourquoi c'est important : si votre cible profile les requetes par OS, ou si votre equipe effectue des tests A/B pour determiner quelle pile contourne un blocage precis, vous pouvez desormais garder cette variable constante pendant que le reste change.
Single resout les verifications de calcul de SiteGround et d'eBay
Deux protections qui imposaient auparavant une redirection vers Browser passent desormais sur Single. eBay utilise son propre defi de preuve de travail (un puzzle Argon2) et SiteGround execute sa propre verification sur une partie des sites en hebergement mutualise. Les deux se resolvent sans rendu graphique, ce qui signifie que la reponse revient sous la forme d'une simple requete HTTP et est facturee comme telle.
Le signal de protection dans les reponses a egalement ete etendu. Les reponses de Browser incluent desormais defenses: { present, cleared }, vous permettant ainsi de voir quel fournisseur protegeait la page et si nous avons reussi a passer. La facturation suit la meme regle : tout fournisseur neutralise est attribue, quelle que soit la marque. Avant cette mise a jour, un seul service de verification etait facture comme une page interactive. Trois autres s'y ajoutent desormais.
Vue d'activite reconstruite dans le Dashboard
Deux colonnes de la liste Activity du Dashboard affichaient des informations incorrectes. La methode HTTP affichait toujours POST sur chaque ligne (tous nos endpoints etant en POST, la colonne etait une constante inutile). De plus, l'IP cliente des appels du Playground enregistrait le serveur d'origine du Playground, et non la personne qui cliquait sur Run.
Ces deux points sont corriges. La colonne methode affiche desormais le verbe envoye dans le corps de la requete. L'IP cliente sur les lignes du Playground affiche maintenant l'IP du navigateur de l'utilisateur connecte, transmise via un token de Playground signe afin qu'un client API ne puisse pas l'usurper.
Le reste de la vue a ete repense au passage. Le tableau s'adapte a un ecran d'ordinateur portable sans masquer de colonnes, la colonne produit est integree a la ligne de requete, et le panneau de details integre des onglets pour que la requete, la reponse et le resume des protections disposent chacun de leur propre defilement.
Facturation : 3D Secure lors d'un changement de forfait
Si l'emetteur de votre carte exigeait une confirmation 3DS lors d'un changement de forfait (et pas uniquement a l'inscription initiale), cette etape ne se declenchait pas et le changement etait silencieusement annule. Elle se declenche desormais. Si vous avez tente de changer de forfait le mois dernier sans resultat visible, c'en etait la cause.
Sous le capot
Le Playground refuse de construire un header de reponse a partir des donnees d'un site recupere (un type de bug par injection de header detecte tot). Un endpoint de facturation sur le Dashboard verifie desormais que l'appelant possede la ressource avant de repondre, fermant ainsi une faille IDOR.
Le pipeline de déploiement lui-même a bénéficié d'une semaine intensive de correctifs après qu'une panne survenue le 6 a saturé le disque de l'hôte de déploiement en plein build. Chaque service refuse désormais de se compiler sans espace disque suffisant, les déploiements sont sérialisés pour éviter les conflits d'accès concurrents, la passerelle reste active lorsqu'un backend oscille, et les services se terminent réellement sur SIGTERM au lieu de rester bloqués jusqu'à être arrêtés brutalement trente secondes plus tard.
Pendant longtemps, le choix de la signature de navigateur vous était imposé par notre équipe. Ce n'est plus une fatalité.