Arkose Labs FunCaptcha expliqué : défis d'application et résolution
Arkose Labs, que beaucoup de développeurs connaissent encore sous le nom de FunCaptcha, est un fournisseur de captcha utilisé par de grands sites pour les inscriptions, les connexions et les paiements. Sa fonctionnalité la plus connue est le défi d'application : un court puzzle façon jeu, comme faire pivoter un objet ou reconnaître un motif, qui apparaît lorsque le moteur de risque estime qu'un visiteur doit subir une vérification supplémentaire. Le support d'Arkose chez Scarnox arrive bientôt. Ce guide explique le fonctionnement de ces défis, pourquoi ils sont plus difficiles que de simples widgets, et les approches générales pour un travail légitime.
Comment un défi Arkose est livré
La page protégée charge un script Arkose et lui transmet une clé publique qui identifie le site. Le défi lui-même est servi par le fournisseur, et le widget renvoie la réponse du visiteur sous la forme d'un token. Comme pour les autres widgets à token, le backend du site vérifie ce token auprès du fournisseur avant de faire confiance au résultat.
La clé publique est l'identifiant que vous cherchez lorsque vous travaillez sur une page, de la même manière qu'une sitekey identifie un widget PopularCaptcha ou reCAPTCHA. Le guide pour trouver la sitekey d'un captcha explique comment localiser ces identifiants sur une page.
À quoi ressemblent les défis
Les défis Arkose sont généralement courts et visuels. Par exemple : faire pivoter une image jusqu'à ce qu'elle soit droite, sélectionner l'élément correspondant dans un ensemble, ou suivre une séquence dans une scène 3D. Le design change souvent, et chaque site peut utiliser un jeu de défis différent. Le puzzle est aussi un signal en soi : la façon dont le visiteur bouge et le temps qu'il met peuvent compter autant que la réponse finale.
Le moteur de risque
Avant d'afficher un défi, le fournisseur évalue la session. Le score repose sur des signaux du navigateur, les caractéristiques de l'appareil, l'historique des requêtes et le comportement sur la page. Un visiteur à faible risque peut passer sans aucun défi. Un visiteur à risque plus élevé voit un ou plusieurs puzzles, et un visiteur à risque très élevé peut être bloqué.
Comme le moteur de risque est réglé pour chaque site et évolue dans le temps, une approche générique qui fonctionne sur un site peut échouer sur un autre. C'est l'une des raisons pour lesquelles les défis d'application sont plus difficiles à gérer que de simples widgets.
Pourquoi l'automatisation déclenche le défi
L'automatisation est signalée pour les mêmes raisons que les autres contrôles fondés sur un score : un navigateur headless par défaut, une nouvelle session sans historique, un rythme de requêtes rapide et régulier, et des adresses réseau à mauvaise réputation. Chaque signal ajoute au score de risque. Le défi demande ensuite quelque chose que l'automatisation fait mal, comme un glissement précis et naturel.
Approches légitimes
Pour vos propres tests et pour des flux de travail légitimes, ces approches réduisent les défis inutiles :
- Utiliser un vrai profil de navigateur aux réglages cohérents, plutôt qu'une version d'automatisation allégée.
- Garder des sessions continues pour que le visiteur ne paraisse pas nouveau à chaque page.
- Espacer les requêtes à un rythme qu'une personne pourrait raisonnablement produire.
- Utiliser l'environnement de test du fournisseur si le site vous appartient. Arkose et la plupart des grands fournisseurs proposent un moyen de tester une intégration sans scoring de risque réel.
- Demander au propriétaire du site une liste blanche, une API ou une alternative accessible si votre travail est légitime mais toujours bloqué.
Ces approches réduisent la fréquence d'apparition des défis. Elles ne suppriment pas le droit du fournisseur de contester une session, et elles ne doivent pas servir à contourner la protection de connexion sur des comptes qui ne vous appartiennent pas.
Ce que ferait un solveur Arkose
Un solveur Arkose fondé sur des tokens prendrait la clé publique et l'URL de la page, produirait un token valide et le renverrait à votre code. Votre code soumettrait ensuite ce token avec le formulaire avant son expiration. La forme de l'intégration ressemblerait au flux PopularCaptcha actuel, mais les détails diffèrent, et Scarnox documentera le type de tâche et les champs dans la référence de l'API lorsque le support sera livré.
Scarnox ne résout pas Arkose en direct aujourd'hui. Le seul type de tâche disponible est PopularCaptcha, sans proxy. Le support d'Arkose arrive bientôt.
Où se situe la limite éthique
Les défis d'application existent pour protéger les pages de connexion, les flux de paiement et les formulaires d'inscription contre les abus. Utiliser un solveur, quel qu'il soit, sur ces flux pour se connecter à des comptes qui ne vous appartiennent pas, pour créer des faux comptes ou pour acheter des stocks limités avant les autres clients est hors cadre. Scarnox ne prend pas en charge ces usages. Un travail légitime sur un site protégé doit commencer par le propriétaire du site, et sa réponse détermine ce qui est autorisé.
Ce qu'il faut vérifier avant un travail
Avant de planifier tout travail sur un flux protégé par Arkose, répondez à quelques questions. Le flux vous appartient-il ? Si oui, l'environnement de test du fournisseur et votre propre copie de staging sont le lieu pour construire et tester. Le travail est-il légitime ? Collecter des informations publiques d'une manière que le site autorise est légitime ; se connecter à des comptes qui ne sont pas les vôtres, ou créer des comptes en masse, ne l'est pas. Le site propose-t-il une API ou un flux de données qui rend le workflow navigateur inutile ? Beaucoup de sites le font, et c'est plus rapide et plus stable que d'automatiser un défi.
Ensuite, regardez le volume. Les défis d'application réagissent au comportement dans le temps : un travail qui tourne à un rythme bas et régulier reçoit généralement moins de défis qu'une rafale lancée d'un seul coup. Planifiez la fréquence en conséquence, et assurez-vous que le travail s'arrête et signale le problème lorsqu'il rencontre un défi pour lequel il n'a pas été conçu, au lieu de réessayer en boucle.
Enfin, décidez à l'avance de ce que fait le travail lorsque le défi ne peut pas être accompli. Un échec propre avec une entrée dans le journal vaut bien mieux qu'une tempête de nouvelles tentatives qui perturbe le site et finit par bloquer votre trafic.
Scrapez de manière responsable
Si le site protégé est celui que vous prévoyez de scraper, consultez d'abord le robots.txt et les conditions d'utilisation. Gardez un rythme faible, évitez les données personnelles dont vous n'avez pas besoin, et cherchez une API avant de construire un workflow navigateur. Le guide sur la légalité du web scraping couvre les principales questions.