Utiliser le SDK Node.js dans AWS Lambda

1. 1.

   Installez la dépendance

   Initialisez un paquet npm dans un répertoire de compilation vierge. Utilisez npm pour installer l’archive officielle à l’adresse https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz. Elle fournit l’import @solvethree/sdk ; ne supposez pas qu’une version est publiée sur le registre npm.

2. 2.

   Configurez l’espace de travail et la cible

   Définissez des variables d’environnement Lambda privées nommées SOLVETHREE_API_KEY, CAPTCHA_SITE et SOLVETHREE_PROXY. Utilisez une clé API d’espace de travail, le nom d’hôte cible plutôt qu’une URL complète et le proxy de cette tâche. L’espace de travail doit déjà disposer d’un profil actif pour ce site ; consultez la configuration du profil de site.

3. 3.

   Enregistrez et empaquetez le gestionnaire

   Enregistrez l’exemple ci-dessous sous le nom index.mjs. Créez un ZIP contenant index.mjs, les métadonnées du paquet et le répertoire node_modules installé à la racine de l’archive, et non dans un répertoire de projet englobant. Ne placez pas d’identifiants dans le ZIP.

4. 4.

   Déployez via votre processus Lambda existant

   Utilisez l’environnement d’exécution Node.js 22 et définissez le gestionnaire sur index.handler. Invoquez-le via votre backend autorisé ou votre flux IAM, en fournissant un requestId stable pour le traitement logique. Gardez les données de solution renvoyées privées.

L’exemple utilise l’action login ; remplacez-la par l’action attendue par votre cible avant le déploiement. Il envoie un seul proxy et utilise le type de requête par défaut enterprise-v3. N’ajoutez pas de champs reCAPTCHA type ni url.

import { Solvethree, SolvethreeError, TaskFailedError, ApiError } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
export const handler = async (event, context) => {
  const timeoutMs = Math.min(180000, context.getRemainingTimeInMillis() - 1500);
  if (timeoutMs < 1000) throw new Error('Not enough execution time to start a task');
  // The caller supplies one stable ID for this logical job; Lambda retries must
  // reuse it. awsRequestId changes with invocations and is not that logical ID.
  if (!event.requestId) throw new Error('Provide a stable requestId');
  try {
    return await client.solve({
      site: process.env.CAPTCHA_SITE, action: 'login', proxy: process.env.SOLVETHREE_PROXY,
      requestId: event.requestId,
    }, { timeoutMs, signal: AbortSignal.timeout(timeoutMs) });
  } catch (error) {
    if (error instanceof TaskFailedError) return { status: 'failed', id: error.taskId, errorCode: error.errorCode };
    if (error instanceof ApiError) return { apiError: error.status, requestId: error.requestId };
    if (error instanceof SolvethreeError) return { interrupted: true, requestId: error.requestId, taskId: error.taskId };
    throw error;
  }
};
// Invoke through your authorized backend/IAM flow. The return value is private
// solution data; do not attach this handler to an unauthenticated public URL.

Le gestionnaire lit le temps d’exécution restant de Lambda, réserve 1,500 millisecondes et plafonne l’attente du SDK à 180,000 millisecondes. Ce plafond est propre à cet exemple ; ce n’est pas une limite d’exécution universelle de Lambda. S’il reste moins d’une seconde après déduction de la réserve, le gestionnaire refuse de démarrer.

Le délai d’expiration du SDK et le signal d’annulation utilisent tous deux l’échéance calculée. solve crée la tâche une seule fois et l’interroge jusqu’à ce qu’elle soit prête ou qu’une erreur survienne. La réserve laisse au traitement des erreurs le temps de renvoyer les informations de récupération, mais un arrêt forcé de Lambda peut toujours empêcher toute réponse.

L’appelant doit conserver event.requestId lors des nouvelles tentatives d’invocation. Utilisez 1–64 lettres ASCII, chiffres, traits de soulignement ou traits d’union. N’utilisez pas awsRequestId : il identifie une invocation, pas la requête logique de résolution.

Les erreurs de validation et les erreurs inattendues sont relancées. Le gestionnaire ne transforme pas toutes les exceptions en réponses d’interruption.

1. 1.

   Récupérez la tâche par son identifiant lorsqu’il est disponible

   Récupérez la tâche existante avec getTask. pending et solving signifient qu’elle est toujours en cours ; seul ready contient une solution utilisable. Limitez toute attente supplémentaire au temps restant de la nouvelle invocation.

2. 2.

   Sinon, récupérez la tâche par l’identifiant de requête logique

   Renvoyez la même demande de tâche avec le requestId initial de l’appelant. Si les paramètres sont identiques, la tâche existante est renvoyée ; s’ils diffèrent, un conflit est signalé. Conservez le même site, la même action et le même proxy pendant la récupération, y compris après des changements de configuration.

Un délai de connexion dépassé ne prouve pas que la création de la tâche a échoué. Récupérez la tâche existante avant d’attribuer un nouvel identifiant de requête logique. Consultez l’interrogation des tâches et la gestion des erreurs de l’API pour connaître les contrats sous-jacents.

Le SDK renvoie les données de la solution ; il ne les applique pas à la cible. Lorsque votre application les soumet, utilisez le proxy configuré ainsi que les valeurs userAgent et secChUa renvoyées. Ne les remplacez pas par une identité de navigateur ou une URL cible sans rapport. Une tâche prête signifie qu’une solution a été générée, pas que la cible a accepté la requête suivante.