Scarnox · Blog

CI grün halten, wenn Ihre App ein Captcha hat

Ihr Registrierungsformular hat ein PopularCaptcha. Ihre End-to-End-Suite muss sich registrieren. Jetzt ist die CI rot, und die verlockende Lösung, das Captcha im Testbuild abzuschalten, heißt, dass der Ablauf, den Sie testen, nicht der Ablauf ist, den Ihre Nutzer bekommen.

Es gibt mehrere Wege heraus. Sie unterscheiden sich darin, wie viel vom echten Ablauf sie abdecken, also wählen Sie den, der zu der Frage passt, die Ihr Test beantwortet. Hier sind die Optionen, grob von günstig bis realistisch.

Scarnox löst PopularCaptcha heute. Andere Captcha-Typen kommen bald, daher gilt die Lösungsoption unten nur für PopularCaptcha.

1. Testschlüssel für Unit- und lokale Tests

Viele Captcha-Anbieter veröffentlichen Testschlüssel, die immer bestehen. Verwenden Sie sie, wenn Sie die Umgebung kontrollieren und nur prüfen müssen, dass das Formular angezeigt und abgesendet wird. Testschlüssel prüfen keine echte Verifizierung, und sie helfen nicht, sobald Sie eine deployte Umgebung mit echten Schlüsseln testen.

2. Eine Umgehung für Ihr eigenes Staging

Manche Teams fügen einen geheimen Header hinzu, den das Backend anstelle eines Captcha-Tokens akzeptiert. Das ist schnell und kostenlos, aber es ist ein Codepfad, der nur für Tests existiert und der mit einer einzigen Fehlkonfiguration in der Produktion landen kann. Wenn Sie einen verwenden, sperren Sie ihn hinter einer Umgebungsprüfung, machen Sie das Geheimnis lang und zufällig, und testen Sie, dass es in der Produktion abgelehnt wird.

3. Den Verifizierungsaufruf mocken

Stubben Sie die serverseitige Verifizierungsanfrage in Integrationstests. Das ist gut, um Ihre Backend-Logik zu prüfen, etwa was passiert, wenn die Verifizierung fehlschlägt. Es sagt Ihnen nichts darüber, ob das Frontend das Token korrekt sendet, daher kombinieren Sie es mit einer der anderen Optionen.

4. In Staging und Smoke-Tests echt lösen

Wenn Sie beweisen müssen, dass der echte Ablauf Ende zu Ende funktioniert, mit echten Schlüsseln, dem echten Widget und der echten Verifizierung, holen Sie ein Token im Test von einer Solver-API. Dies ist die einzige Option, die eine defekte Widget-Integration aufdeckt.

Ein Playwright-Helfer sieht so aus:

// Playwright-Testhelfer
export async function solveCaptcha(page) {
  const sitekey = await page.getAttribute("[data-sitekey]", "data-sitekey");
  const r = await fetch("https://api.scarnox.com/api/tasks/create", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SCARNOX_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      captcha_type: "PopularCaptchaTaskProxyless",
      site_key: sitekey,
      site_url: page.url(),
    }),
  });
  const { errorId, solution, errorCode, errorDescription } = await r.json();
  if (errorId !== 0) throw new Error(`${errorCode}: ${errorDescription}`);

  await page.evaluate((t) => {
    document.querySelectorAll('[name="h-captcha-response"],[name="g-recaptcha-response"]')
      .forEach((el) => { el.value = t; });
  }, solution.token);
}

Rufen Sie ihn im Test direkt vor dem Absenden des Formulars auf, nicht am Anfang des Tests. Tokens laufen innerhalb von etwa zwei Minuten ab, und ein langsamer Schritt früher im Test kann dieses Zeitfenster aufbrauchen.

Lösungen auf ein Minimum beschränken

Eine Suite, die sich bei jedem Lauf registriert, kann im Laufe einer Woche viele Lösungen erzeugen. Halten Sie die Zahl niedrig:

Für Wiederholungsregeln innerhalb des Helfers übernehmen Sie die Richtlinie aus Fehlerbehandlung und Backoff.

Den Schlüssel aus dem Repository heraushalten

Speichern Sie den Schlüssel als CI-Geheimnis, etwa mit dem Namen SCARNOX_KEY, und legen Sie ihn nie in den Testcode oder die Fixtures. Wenn er durchsickert, erzeugen Sie ihn im Dashboard neu. Der alte Schlüssel funktioniert sofort nicht mehr, sodass ein durchgesickerter Schlüssel nicht lange genutzt werden kann, um Lösungen auszuführen.

Verwenden Sie einen eigenen Schlüssel für die CI. Wenn sich eine Pipeline schlecht verhält, können Sie diesen Schlüssel rotieren, ohne alles andere anzufassen.

Auf Ihrem eigenen Staging ausprobieren

Erstellen Sie ein Konto und starten Sie mit einer kostenlosen Testphase, ganz ohne Karte. Binden Sie den Helfer zuerst in einen einzelnen Smoke-Test ein, bestätigen Sie, dass die Registrierung sauber durchläuft, und fügen Sie ihn erst dann der übrigen Suite hinzu. Was das Lösen im größeren Maßstab kostet, sehen Sie in den aktuellen Preisen.

Was nach dem Absenden zu prüfen ist

Eine gelöste Captcha-Prüfung beweist nur, dass der Widget-Schritt funktioniert hat. Prüfen Sie nach dem Absenden die Dinge, die für den Nutzer zählen: Die nächste Seite lädt, die Erfolgsmeldung erscheint, und das Konto oder die Bestellung existiert in Ihrer Datenbank. Ein Test, der bei "kein Fehler im Formular" stehen bleibt, kann bestehen, während die Registrierung im Backend stillschweigend fehlschlägt.

Halten Sie die Prüfungen nah am geschäftlichen Ergebnis. Prüfen Sie die URL, die sichtbare Meldung und einen Datensatz, den der Test angelegt hat. Räumen Sie diesen Datensatz am Ende des Laufs wieder auf, damit der nächste Lauf von einem bekannten Zustand startet.

Den Smoke-Test nach Zeitplan ausführen

Führen Sie den Smoke-Test mit echter Lösung nach Zeitplan aus, zum Beispiel einmal täglich gegen Staging, statt bei jedem Pull Request. Geplante Läufe fangen Änderungen auf, die die Website über Nacht vorgenommen hat, etwa eine neue Widget-Version oder einen verschobenen Sitekey, ohne bei jedem Commit Lösungen zu verbrauchen. Benachrichtigen Sie das Team, wenn der geplante Lauf fehlschlägt, und halten Sie die Suite pro Commit bei den schnelleren Optionen.

Nächste Schritte