Das Node.js SDK in AWS Lambda verwenden

1. 1.

   Abhängigkeit installieren

   Initialisieren Sie ein npm-Paket in einem sauberen Build-Verzeichnis. Installieren Sie mit npm das offizielle Tarball-Archiv unter https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz. Es stellt den Import @solvethree/sdk bereit; gehen Sie nicht davon aus, dass eine Veröffentlichung in der npm-Registry existiert.

2. 2.

   Workspace und Ziel konfigurieren

   Legen Sie private Lambda-Umgebungsvariablen namens SOLVETHREE_API_KEY, CAPTCHA_SITE und SOLVETHREE_PROXY fest. Verwenden Sie einen Workspace-API-Schlüssel, den Zielhostnamen statt einer vollständigen URL und den Proxy für diese Aufgabe. Der Workspace muss bereits ein aktives Profil für diese Website haben; siehe Websiteprofil einrichten.

3. 3.

   Handler speichern und paketieren

   Speichern Sie das folgende Beispiel als index.mjs. Erstellen Sie eine ZIP-Datei mit index.mjs, den Paketmetadaten und dem installierten Verzeichnis node_modules direkt im Stammverzeichnis des Archivs – nicht in einem übergeordneten Projektverzeichnis. Legen Sie keine Zugangsdaten in der ZIP-Datei ab.

4. 4.

   Über Ihren bestehenden Lambda-Prozess bereitstellen

   Verwenden Sie die Node.js 22-Laufzeit und setzen Sie den Handler auf index.handler. Rufen Sie ihn über Ihr autorisiertes Backend oder Ihren IAM-Ablauf auf und geben Sie eine stabile requestId für den logischen Auftrag an. Halten Sie die zurückgegebenen Lösungsdaten privat.

Das Beispiel verwendet die Aktion login; ändern Sie diese vor der Bereitstellung in die Aktion, die Ihr Ziel erwartet. Es sendet einen proxy und verwendet den Standardanfragetyp enterprise-v3. Fügen Sie keine reCAPTCHA-Felder type oder url hinzu.

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.

Der Handler liest die verbleibende Ausführungszeit von Lambda aus, reserviert 1,500 Millisekunden und begrenzt die SDK-Wartezeit auf 180,000 Millisekunden. Diese Obergrenze gehört zu diesem Beispiel; sie ist kein allgemeines Ausführungslimit von Lambda. Wenn nach Abzug der Reserve weniger als eine Sekunde verbleibt, verweigert der Handler den Start.

Sowohl das SDK-Zeitlimit als auch das Abbruchsignal verwenden die berechnete Frist. solve erstellt die Aufgabe einmal und fragt sie ab, bis sie fertig ist oder ein Fehler auftritt. Die Reserve gibt der Fehlerbehandlung Zeit, Wiederherstellungsinformationen zurückzugeben; eine erzwungene Beendigung durch Lambda kann dennoch jede Antwort verhindern.

Der Aufrufer muss event.requestId über wiederholte Aufrufe hinweg beibehalten. Verwenden Sie 1–64 ASCII-Buchstaben, Ziffern, Unterstriche oder Bindestriche. Verwenden Sie nicht awsRequestId: Diese ID kennzeichnet einen Aufruf, nicht die logische Lösungsanfrage.

Validierungsfehler und unerwartete Fehler werden erneut ausgelöst. Der Handler wandelt nicht jede Ausnahme in eine Unterbrechungsantwort um.

1. 1.

   Wenn vorhanden, anhand der Aufgaben-ID wiederherstellen

   Rufen Sie die vorhandene Aufgabe mit getTask ab. pending und solving bedeuten, dass sie noch läuft; nur ready enthält eine nutzbare Lösung. Begrenzen Sie jede weitere Wartezeit auf das verbleibende Zeitbudget des neuen Aufrufs.

2. 2.

   Andernfalls anhand der logischen Anfrage-ID wiederherstellen

   Wiederholen Sie dieselbe Task-Anfrage mit der ursprünglichen requestId des Aufrufers. Bei übereinstimmenden Eingaben wird der bestehende Task zurückgegeben; abweichende Eingaben führen zu einem Konflikt. Lassen Sie Website, Aktion und Proxy bei der Wiederherstellung unverändert, auch über Konfigurationsänderungen hinweg.

Ein Verbindungs-Timeout beweist nicht, dass die Task-Erstellung fehlgeschlagen ist. Stellen Sie den bestehenden Task wieder her, bevor Sie eine neue logische Anfrage-ID vergeben. Die zugrunde liegenden Regeln finden Sie unter Task-Polling und API-Fehlerbehandlung.

Das SDK gibt Lösungsdaten zurück; es wendet sie nicht auf das Ziel an. Wenn Ihre Anwendung sie übermittelt, verwenden Sie den konfigurierten Proxy sowie die zurückgegebenen Werte für userAgent und secChUa. Ersetzen Sie diese nicht durch eine andere Browseridentität oder Ziel-URL. Ein fertiger Task bedeutet, dass eine Lösung generiert wurde – nicht, dass das Ziel die anschließende Anfrage akzeptiert hat.