Points clés
Vous pouvez désormais composer, envoyer et rejouer des requests avec votre propre clé API directement depuis le dashboard. Le nouveau playground couvre les trois produits et conserve les cookies, les presets et l'historique d'une exécution à l'autre. Deux correctifs de fiabilité l'accompagnent : unblocker: true subissait une dégradation silencieuse depuis plusieurs semaines (il fonctionne à nouveau, de bout en bout), et Browser capture désormais le cookie de challenge passif cf_clearance de Cloudflare de manière fiable.
Nouveautés
Le playground du dashboard
/dashboard/#playground est désormais un véritable espace de travail. Trois onglets de produits (Single, Proxy Finder, Browser), une barre d'URL, des headers, un body, ainsi que tous les flags par produit exposés et alignés sur le schéma réel de chaque produit. Envoyez la request, observez le rendu de la response avec les modes de visualisation JSON, HTML et texte. Recherchez dans les volets de response avec Ctrl/Cmd+K. Agrandissez la response sur l'ensemble du viewport lorsque vous devez lire un pavé de HTML.
Quelques détails nés de notre volonté de concevoir cet outil comme nous aimerions l'utiliser nous-mêmes :
- Les cookies que vous recevez sont sauvegardés dans un jar par hôte.
- La request suivante vers le même hôte les associe automatiquement, et vous pouvez inspecter, modifier ou supprimer n'importe quel cookie avant l'envoi.
- Un volet de proxies actifs rassemble chaque proxy id retourné lors d'une exécution réussie de Proxy Finder, vous permettant de cliquer sur "use" et de réutiliser ce proxy dans une request Single ou Browser sans avoir à le retaper.
- Enregistrez des requests en tant que presets. Rejouez n'importe laquelle de vos 20 dernières exécutions depuis une boîte de dialogue d'historique.
- Un générateur de commande curl affiche la commande exacte (avec
x-api-key) que vous lanceriez depuis un terminal pour envoyer la même request.
Le playground signe un token interne à courte durée de vie, de sorte que votre clé en clair ne quitte jamais le dashboard. Le quota, les métriques et last_used_at sont imputés à la clé que vous avez choisie, de la même manière que si vous aviez envoyé la request depuis votre propre code.
unblocker: true fonctionne à nouveau, de bout en bout
Nous avons détecté un problème de build qui dégradait silencieusement les requests Single et Proxy Finder avec unblocker: true au cours des dernières semaines. Le build a été déployé sans que le bypass ne soit réellement câblé, de sorte que les requests qui auraient dû franchir les barrières anti-bots au niveau du handshake recevaient à la place une signature de request générique. Des sites qui auraient dû nous laisser passer nous bloquaient.
Le correctif est déployé. Nous avons vérifié le fonctionnement de bout en bout sur onze cibles réelles, dont trois avec des interstitiels Cloudflare qui nécessitaient auparavant Browser pour être franchis. Single les franchit désormais seul. Le flux enchaîné Proxy Finder + Browser + Single (trouver un proxy, obtenir un cookie cf_clearance de Browser, envoyer la request de page avec Single en y ajoutant le cookie et le même proxy) renvoie le HTML complet en un seul aller-retour.
Cette erreur est de notre fait. unblocker: true fonctionnait le jour de sa sortie et s'est cassé discrètement lors d'un rebuild de routine. Si vous avez exécuté une request avec unblocker: true contre un site protégé ces dernières semaines et que vous avez obtenu un 403 au lieu du 200 attendu, c'en est la raison. Réessayez.
Browser gère le challenge JavaScript passif de Cloudflare
Cloudflare dispose de deux modes de challenge. Le mode actif (HTTP 403 plus interstitiel) était déjà pris en charge. Le mode passif est plus sournois : la page renvoie immédiatement un code 200, mais Cloudflare injecte une sonde JavaScript asynchrone qui analyse l'empreinte (fingerprint) du client et émet seulement ensuite le cookie cf_clearance. Avant ce correctif, Browser finalisait la response avant que la sonde ne puisse terminer son exécution, de sorte que le cookie de clearance n'arrivait jamais dans le jar.
Désormais, Browser écoute explicitement l'événement Set-Cookie et attend cf_clearance s'il détecte le marqueur de challenge passif dans le body. Pas de polling, pas de période de grâce fixe, pas d'attente supplémentaire pour les sites non-Cloudflare. Douze domaines réels de la suite de tests, dont trois sur le chemin passif, renvoient désormais des cookies de clearance de manière fiable.
Correction d'une faille SSRF à l'edge de l'API
Une clé API pk_live_... valide ne constitue pas une autorisation d'accéder à notre réseau privé. L'API rejette désormais toute cible dont le nom d'hôte littéral ou la résolution DNS aboutit à un bloc réservé RFC 5735, 6598 ou IPv6. Le même contrôle est exécuté sur chaque produit backend en guise de seconde ligne de défense.
Vous ne verrez aucune différence en surface. Nous bloquons une classe de sondage de réseau interne avant même qu'elle ne puisse finaliser un handshake TCP.
Previews sociales uniques pour le blog et correction de la pagination
Chaque article de blog génère désormais sa propre image Open Graph, avec le titre et l'excerpt de l'article rendus sur une carte aux couleurs de la marque. Collez un lien foura.ai/blog/... dans Discord, LinkedIn, Slack ou Twitter et vous verrez s'afficher la preview spécifique à l'article au lieu d'un visuel générique par défaut.
La pagination sur l'index du blog était discrètement cassée. Le bouton "Older" vous renvoyait vers la page 1. Nous l'avons reconstruite sur des URL basées sur le chemin (/blog/page/N/), avons ajouté une navigation numérotée avec une fenêtre intelligente, et avons intégré des balises de lien rel=prev/next appropriées pour les séries paginées. Les anciennes URL ?page=N effectuent une redirection 301 vers le nouveau format, de sorte que rien de ce qui a été indexé auparavant n'est perdu.
Sous le capot
Notre serveur MCP est en ligne à l'adresse mcp.foura.ai pour tous les outils LLM compatibles avec le Model Context Protocol. L'authentification utilise le même token Bearer pk_live_... que celui que vous utilisez pour l'API REST. Il expose les trois produits sous forme d'outils (Single, Proxy Finder, Browser) ainsi qu'une poignée de prompts. Si vous intégrez FourA dans Claude Code ou tout autre agent compatible MCP, vous pouvez cesser d'exécuter un bridge local.
Si vous hésitiez à utiliser le dashboard parce que le précédent playground n'était qu'une ébauche, ouvrez-le cette semaine. C'est l'interface que nous utilisons désormais nous-mêmes lorsque quelque chose semble anormal avec une cible d'API.