FourA Digest, du 12 au 19 juin 2026

Points clés

Deux changements cette semaine affectent ce que renvoient vos requests. Les corps de response ne s'affichent plus sous forme de mojibake sur les sites non-UTF-8, et les responses non-200 acceptées par validate comptent enfin comme des succès au lieu d'échecs. Nous avons également corrigé quelques failles de sécurité sur l'API client.

Nouveautés

Les pages non-UTF-8 renvoient du texte lisible sur Single

Si vous appelez Single sur des forums bulgares, des sites d'e-commerce chinois, des actualités japonaises ou tout ce qui envoie du windows-1251, GBK, Big5 ou Shift_JIS, le corps de la response revenait auparavant sous forme d'octets corrompus. La couche HTTP sous-jacente utilisait un décodeur UTF-8 codé en dur, de sorte qu'une page en cyrillique arrivait sous la forme промоции et il était impossible de récupérer l'original de votre côté.

Ce problème est résolu au niveau de la couche request. Single détecte désormais le charset source (via le header Content-Type, puis <meta charset>, puis <meta http-equiv>) et le transcode en UTF-8 avant que le corps n'atteigne votre enveloppe JSON. Les pages en UTF-8 ou ASCII passent sans modification. Le contenu binaire comme les images ou les PDF n'est jamais décodé. Si vous souhaitez obtenir les octets bruts, returnBuffer: true renvoie toujours le buffer d'origine.

Activé par défaut. Aucun flag à activer. Les pages qui fonctionnaient auparavant fonctionnent toujours ; les pages qui renvoyaient des données illisibles affichent désormais du texte lisible. Les utilisateurs de navigateurs n'ont pas non plus à s'en soucier, car Chromium décode les charsets nativement.

Les règles validate déterminent désormais la classification des succès

Lorsque vous définissez validate sur une request (par exemple validate.status.accept = [200, 403]), le moteur de request respectait déjà votre règle et résolvait la response sans erreur. Cependant, notre classificateur de résultats en amont ignorait votre règle et classait tout ce qui n'était pas un 200 littéral comme application_fail. Deux conséquences : votre 403 accepté apparaissait comme un échec dans le Dashboard, et comme seuls les succès sont facturables, ces responses livrées n'étaient pas non plus facturées.

Le classificateur respecte désormais ce que validate a déclaré. Les requests avec validate comptent comme des succès chaque fois que le moteur les a résolues sans erreur, quel que soit le statut. Les requests sans validate se comportent comme avant (succès uniquement sur 200), le chemin historique reste donc inchangé.

Correctif non rétroactif : les lignes historiques conservent leur résultat enregistré, les nouvelles requests sont classées correctement. Si vous voyiez des App Fail sur des responses que vous sabiez valides, en voici la raison.

Renforcement de la sécurité sur l'API client

Nous avons déployé la Wave 0 d'un audit de sécurité sur l'API client :

• CORS est désormais limité à https://foura.ai. Le paramètre précédent renvoyait n'importe quelle origine lors de l'envoi des identifiants, ce qui correspond à la configuration CSRF standard. Les appels de navigateur de même origine (same-origin) et vos appels API côté serveur ne sont pas affectés.
• La route des métriques derrière votre historique d'activité acceptait auparavant un filtre outcome libre qui s'injectait directement dans la requête. Elle est désormais restreinte par une liste d'autorisation (allowlist) aux valeurs de résultats connues. Ce n'était pas exploitable depuis un compte normal, mais cela méritait d'être corrigé.

Aucun de ces changements ne modifie le contrat de l'API. Vous ne les remarquerez pas en utilisation normale. Mais identifier un problème et le résoudre avant que quiconque ne s'en rende compte mérite tout de même d'être mentionné.

Les libellés d'activité correspondent à la vue d'ensemble

Un détail mineur. Le tableau d'activité de votre Dashboard affichait auparavant des chaînes de caractères brutes pour les résultats, comme Application_fail, tandis que les badges, le graphique en anneau et l'historique de la vue d'ensemble affichaient des libellés plus clairs (App Fail) et un code couleur pour chaque résultat. Les mêmes données, deux présentations. Ils sont désormais synchronisés et lisent tous deux la même table de correspondance de libellés et de couleurs, de sorte que le statut d'une ligne reste identique quel que soit l'endroit où vous le vérifiez.

Chiffres

Cette semaine n'apporte pas de nouveaux chiffres sur la latence ou le taux de réussite. L'essentiel de ce travail porte sur la correction et la sécurité, où la bonne métrique consiste à "arrêter de se tromper" plutôt qu'à "aller plus vite". Le digest de la semaine prochaine devrait contenir des données de débit sur plusieurs projets en cours.