Gardez votre clé API CAPTCHA hors du JavaScript du navigateur

Une clé d’espace de travail authentifie les requêtes vers solvethree avec Authorization: Bearer. La placer dans le JavaScript du navigateur, y compris via une variable d’environnement publique intégrée au bundle comme NEXT_PUBLIC_SOLVETHREE_API_KEY, expose cet identifiant au navigateur. Obfusquer sa valeur ou ne l’ajouter qu’au moment d’un appel fetch direct ne la rend pas privée.

Conservez SOLVETHREE_API_KEY dans une configuration exclusivement côté serveur et utilisez-la uniquement depuis du code serveur de confiance. Le navigateur doit appeler la route de votre application, jamais l’API de tâches solvethree avec la clé de votre espace de travail.

// Import only from trusted server code. Your application authenticates the caller.
import { Solvethree } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
export async function createCaptchaForLogin(requestId) {
  return client.createTask({
    site: process.env.CAPTCHA_SITE,
    action: 'login',
    proxy: process.env.SOLVETHREE_PROXY,
    requestId,
  }, { waitMs: 0, signal: AbortSignal.timeout(20000) });
}
// The browser calls your authenticated application route, not the solver API.
// Save the returned task ID; retrieve that ID from server code with getTask.
// Submit a ready token using the proxy/browser identity attached to that solve.
// Merely moving the key server-side does not configure the browser's proxy.

Configurez SOLVETHREE_API_KEY, CAPTCHA_SITE et SOLVETHREE_PROXY sur le serveur. CAPTCHA_SITE est le nom d’hôte cible, pas une URL complète. La fonction utilitaire fixe l’action à login et fournit un seul proxy ; le navigateur ne choisit aucun de ces paramètres.

Configurez un profil actif pour ce nom d’hôte dans l’espace de travail avant d’appeler la fonction utilitaire. Envoyer site et action n’en crée pas. Consultez la configuration d’un profil de site.

waitMs: 0 demande la création sans attendre la fin de la résolution. Enregistrez l’ID de tâche renvoyé et récupérez la tâche depuis le code serveur avec getTask. Le signal d’annulation de 20 secondes de la fonction utilitaire limite la durée de cette requête ; il ne garantit pas que la résolution se termine en 20 secondes.

La fonction utilitaire ne constitue pas à elle seule une route authentifiée. Ajoutez ces contrôles autour d’elle avant d’accepter les requêtes du navigateur :

Ne transmettez pas un corps de tâche fourni par le navigateur. Refusez les tentatives de sélection d’un autre nom d’hôte, d’une autre action, d’un autre proxy ou d’un autre type de tâche. Appliquez une limite de création par appelant ou par session de l’application : même un appelant authentifié peut épuiser le crédit en lançant de nouvelles tâches. Si la route utilise une authentification par cookie, protégez les requêtes de création de tâches contre la falsification de requêtes intersites.

Un ID de tâche ne constitue pas une autorisation. Vérifiez l’appartenance de la tâche à chaque requête de progression et ne renvoyez ni les identifiants de l’espace de travail ni ceux du proxy serveur dans les réponses au navigateur.

• Conservez un seul requestId pour la tentative logique de connexion. Validez son format documenté : 1–64 lettres ASCII, chiffres, traits de soulignement ou traits d’union. Associez-le à la tentative de l’appelant ; ce n’est pas un identifiant d’authentification.
• Si la création expire, conservez ce requestId et les paramètres d’origine de la tâche. Répéter la même requête avec le même ID permet de récupérer la tâche existante. Modifier les paramètres tout en réutilisant l’ID provoque un conflit.
• Traitez les réponses HTTP signalant un échec avant d’interpréter un contenu de réponse comme un succès. Pour une tâche récupérée, pending et solving signifient qu’il faut continuer l’interrogation ; ready signifie qu’une solution est disponible.

Une fois que vous avez un ID de tâche, récupérez cette tâche plutôt que de lancer une nouvelle résolution à chaque actualisation du navigateur ou requête de progression. Consultez la gestion des erreurs de l’API pour diagnostiquer les échecs.

Avant de renvoyer un jeton prêt au navigateur, déterminez où la requête vers la cible sera exécutée. Le client qui effectue la soumission doit utiliser l’identité userAgent et secChUa renvoyée ainsi que le proxy ayant permis cette résolution. Déplacer la clé de l’espace de travail vers un backend ne configure pas le proxy du navigateur.

Si le navigateur ne peut pas effectuer la soumission avec ces paramètres, lui transmettre uniquement le jeton ne constitue pas une intégration complète. Utilisez un client de soumission que vous pouvez configurer de manière cohérente, sans y mêler l’identité, le proxy ou l’URL cible d’une autre session. Une tâche prête signifie que solvethree a généré une solution, pas que la cible a accepté la requête suivante.