Ergebnisse von CAPTCHA-Aufgaben in TypeScript sicher verarbeiten

Verwenden Sie die vom SDK exportierten Typen TaskRequest für Eingaben und TaskResult für Antworten. Durch die Eingrenzung anhand des Status kann TypeScript zwischen laufender Verarbeitung, Fehlschlag und Bereitschaft unterscheiden – ohne any oder eine Typumwandlung, die dem Compiler lediglich vorgibt, Ihnen zu vertrauen.

import { Solvethree, type TaskRequest, type TaskResult } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY! });
const input: TaskRequest = { site: 'accounts.example.com', action: 'login', proxy: process.env.SOLVETHREE_PROXY! };
function inspect(result: TaskResult): void {
  switch (result.status) {
    case 'pending':
    case 'solving':
      console.log('Retrieve this task again:', result.id);
      return;
    case 'failed':
      console.error('Failed task:', result.id, result.errorCode);
      return;
    case 'ready':
      // Solution fields depend on the requested product; check optional fields.
      if (!result.solution.token || !result.solution.userAgent || !result.solution.secChUa) {
        throw new Error('Expected a complete reCAPTCHA solution');
      }
      console.log('Ready task:', result.id);
      // Submit token privately with its browser identity and original proxy.
      return;
  }
}
inspect(await client.createTask(input, { waitMs: 0 }));
// Save the returned ID and call getTask while pending/solving with a deadline.

Das Beispiel erstellt eine Aufgabe und prüft die unmittelbare Antwort. pending und solving bedeuten, dass sie erneut abgerufen werden muss; failed beendet die Verarbeitung; bei ready folgen die Prüfungen der Lösung. Wenn Sie den ready-Zweig in eine Hilfsfunktion auslagern, verwenden Sie den exportierten Typ ReadyTask für deren Parameter. Das grenzt den Status ein, macht aber nicht jedes produktspezifische Lösungsfeld zum Pflichtfeld.

Die Prüfungen kontrollieren, ob ein Token und beide Felder der Browseridentität vorhanden sind, da diese Eingabe reCAPTCHA anfordert. Sie belegen nicht, dass die Zielwebsite das Token akzeptiert. Das Beispiel gibt das Token bewusst nicht aus.

• Verwenden Sie Node.js 22+ und die in der API-Dokumentation beschriebene Installation des offiziellen SDK-Tarballs; setzen Sie nicht voraus, dass eine Veröffentlichung in der npm-Registry existiert.
• Setzen Sie SOLVETHREE_API_KEY und SOLVETHREE_PROXY in der Serverumgebung. Die !-Zusicherungen prüfen zur Laufzeit nicht, ob Umgebungsvariablen fehlen.
• Ersetzen Sie accounts.example.com und login durch den vorgesehenen Hostnamen und die vorgesehene Aktion. Für die Website muss bereits ein aktives Profil im Workspace vorhanden sein; siehe Website-Profil einrichten.

Das Beispiel überlässt das Polling dem Aufrufer. Halten Sie die Erstellung außerhalb dieser Schleife: Ein erneuter Aufruf von createTask ist nicht der Weg, um zu prüfen, ob die erste Aufgabe abgeschlossen ist.

1. 1.

   Die ID aus dem Erstellungsergebnis speichern

   Prüfen Sie, ob die zurückgegebene ID eine nicht leere Zeichenfolge ist, bevor Sie sie zum Abrufen verwenden. Ordnen Sie sie weiterhin der ursprünglichen Anfrage zu, die Sie auch bei der Auswahl des erfolgreichen Proxys benötigen.

2. 2.

   Dieselbe Aufgabe abrufen

   Rufen Sie getTask mit der gespeicherten ID auf, solange der Status pending oder solving ist, und setzen Sie dabei eine lokale Zeitgrenze. Prüfen Sie vor der Verarbeitung jeder Antwort, ob deren ID mit der gespeicherten ID übereinstimmt. Eine übereinstimmende ID zeigt, welche Aufgabe Sie bearbeiten, nicht, ob sie erfolgreich war.

3. 3.

   Bei einem endgültigen Ergebnis stoppen

   Validieren Sie bei ready die Felder, die das angeforderte Produkt benötigt. Prüfen Sie bei failed sowohl errorCode als auch error und beenden Sie dann das Polling dieser Aufgabe. Behandeln Sie Anfragefehler separat: Eine fehlgeschlagene Abrufanfrage ist für sich genommen kein endgültiges Scheitern der Aufgabe.

Wenn bei der Erstellung eine Zeitüberschreitung auftritt, bevor Sie eine ID erhalten, gehen Sie nicht davon aus, dass keine Aufgabe erstellt wurde. Falls Sie eine requestId angegeben haben, erhalten Sie durch erneutes Senden der identischen Anfrage mit demselben Wert die bestehende Aufgabe zurück. Die Wiederverwendung mit geänderten Eingaben führt zu einem Konflikt; ein neu erzeugter Wert stellt die ursprüngliche Aufgabe nicht wieder her.

Wählen Sie den Handler anhand der ursprünglichen Anfrage und prüfen Sie dann die erwarteten Lösungsfelder. Allein das Vorhandensein eines Tokens unterscheidet eine reCAPTCHA-Antwort nicht von einem TMPT-Cookie-Wert.

Eigenständiges Kasada unterstützt derzeit HTTPS-Ziele auf www.ticketmaster.com, nicht beliebige Websites. Sein Header-Handler ist keine universelle Kasada-Integration.

Übermitteln Sie bei jedem Produkt die Lösung mit den zurückgegebenen Werten userAgent und secChUa sowie dem erfolgreichen Proxy. Verwenden Sie bei Proxy-Kandidaten successfulProxy(originalTask, readyResult), statt anzunehmen, dass der erste Kandidat erfolgreich war. Das SDK wendet die Lösung nicht für Sie auf das Ziel an, und ready garantiert nicht, dass diese nachfolgende Anfrage akzeptiert wird.