Den CAPTCHA-API-Schlüssel aus Browser-JavaScript heraushalten

Ein Workspace-Schlüssel authentifiziert Anfragen an solvethree mit Authorization: Bearer. Wenn Sie ihn in Browser-JavaScript einfügen, auch über eine eingebundene öffentliche Umgebungsvariable wie NEXT_PUBLIC_SOLVETHREE_API_KEY, legen Sie diese Zugangsdaten im Browser offen. Den Wert zu verschleiern oder erst bei einem direkten fetch hinzuzufügen, hält ihn nicht geheim.

Halten Sie SOLVETHREE_API_KEY in einer ausschließlich serverseitigen Konfiguration und verwenden Sie ihn nur in vertrauenswürdigem Servercode. Der Browser sollte Ihre Anwendungsroute aufrufen, niemals die solvethree-Aufgaben-API mit Ihrem Workspace-Schlüssel.

// 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.

Konfigurieren Sie SOLVETHREE_API_KEY, CAPTCHA_SITE und SOLVETHREE_PROXY auf dem Server. CAPTCHA_SITE ist der Zielhostname, keine vollständige URL. Die Hilfsfunktion legt die Aktion auf login fest und gibt einen Proxy vor; der Browser wählt keine dieser Eingaben aus.

Richten Sie vor dem Aufruf der Hilfsfunktion ein aktives Profil für diesen Hostnamen im Workspace ein. Das Senden von site und action erstellt keines. Siehe Website-Profil einrichten.

waitMs: 0 fordert die Erstellung an, ohne auf den Abschluss des Lösungsvorgangs zu warten. Speichern Sie die zurückgegebene Aufgaben-ID und rufen Sie die Aufgabe aus Servercode mit getTask ab. Das Abbruchsignal der Hilfsfunktion nach 20 Sekunden begrenzt diese Anfrage; es garantiert nicht, dass der Lösungsvorgang innerhalb von 20 Sekunden abgeschlossen ist.

Die Hilfsfunktion allein ist noch keine authentifizierte Route. Ergänzen Sie vor dem Annehmen von Browseranfragen die folgenden Prüfungen:

Leiten Sie keinen vom Browser gelieferten Aufgaben-Body weiter. Lehnen Sie Versuche ab, einen anderen Hostnamen, eine andere Aktion, einen anderen Proxy oder Aufgabentyp auszuwählen. Begrenzen Sie die Aufgabenerstellung pro Aufrufer oder Anwendungssitzung: Auch ein authentifizierter Aufrufer kann durch das Starten neuer Aufgaben Guthaben aufbrauchen. Wenn die Route Cookie-Authentifizierung verwendet, schützen Sie aufgabenerstellende Anfragen vor Cross-Site Request Forgery.

Eine Aufgaben-ID ist keine Autorisierung. Prüfen Sie bei jeder Fortschrittsanfrage die Zugehörigkeit und geben Sie in Browserantworten weder Workspace-Zugangsdaten noch Zugangsdaten des Server-Proxys zurück.

• Behalten Sie für den logischen Anmeldeversuch dieselbe requestId bei. Validieren Sie ihr dokumentiertes Format: 1–64 ASCII-Buchstaben, Ziffern, Unterstriche oder Bindestriche. Binden Sie sie an den Versuch des Aufrufers; sie ist kein Authentifizierungsnachweis.
• Wenn bei der Erstellung ein Timeout auftritt, behalten Sie diese requestId und die ursprünglichen Aufgabeneingaben bei. Eine Wiederholung derselben Anfrage mit derselben ID stellt die bestehende Aufgabe wieder her. Geänderte Eingaben bei Wiederverwendung der ID führen zu einem Konflikt.
• Behandeln Sie nicht erfolgreiche HTTP-Antworten, bevor Sie eine Erfolgspayload auswerten. Bei einer abgerufenen Aufgabe bedeuten pending und solving, dass Sie weiter abfragen sollen; ready bedeutet, dass eine Lösung verfügbar ist.

Sobald Sie eine Aufgaben-ID haben, rufen Sie diese Aufgabe ab, statt bei jeder Browseraktualisierung oder Fortschrittsanfrage einen weiteren Lösungsvorgang zu starten. Hinweise zur Fehlerdiagnose finden Sie unter API-Fehlerbehandlung.

Legen Sie vor der Rückgabe eines fertigen Tokens an den Browser fest, wo die Zielanfrage ausgeführt wird. Der übermittelnde Client muss die zurückgegebene Identität aus userAgent und secChUa sowie den erfolgreichen Proxy dieses Lösungsvorgangs verwenden. Das Verschieben des Workspace-Schlüssels ins Backend konfiguriert nicht den Proxy des Browsers.

Wenn der Browser mit diesen Einstellungen nicht übermitteln kann, ist die Übergabe des Tokens allein keine vollständige Integration. Verwenden Sie einen übermittelnden Client, den Sie konsistent konfigurieren können, ohne Identität, Proxy oder Ziel-URL einer anderen Sitzung einzumischen. Eine bereite Aufgabe bedeutet, dass solvethree eine Lösung erzeugt hat – nicht, dass das Ziel die anschließende Anfrage akzeptiert hat.