Scarnox · Blog

Unsichtbares PopularCaptcha lösen: Unterschiede und was du senden musst

Ein unsichtbares PopularCaptcha sieht aus wie gar kein Captcha. Es gibt kein Kästchen mit "Ich bin kein Roboter". Die Seite ruft PopularCaptcha aus ihrem eigenen JavaScript auf, meist wenn der Besucher auf Absenden klickt, und zeigt nur dann eine Aufgabe, wenn sie sich über den Besucher nicht sicher ist. Für ein Automatisierungsskript ist das Widget schwerer zu erkennen, aber die Lösung besteht trotzdem aus einer Anfrage.

Scarnox löst PopularCaptcha heute, auch die unsichtbare Variante. Du setzt ein Flag, is_invisible, und sendest dieselbe Anfrage wie für ein sichtbares Widget. Weitere Captcha-Typen kommen demnächst.

So erkennst du, dass es unsichtbar ist

Das Widget hat data-size="invisible".
Die Seite ruft die Funktion execute() des Widgets in ihrem eigenen Code auf.
Es gibt einen Sitekey in der Seite, aber nirgends ein sichtbares Kästchen.

Die Konfiguration des Sitekeys entscheidet, nicht das Aussehen der Seite. Wenn du unsicher bist, finde den Sitekey und prüfe die Widget-Optionen im JavaScript der Seite.

Was du senden musst

Verwende denselben Endpunkt und denselben Task-Typ und füge is_invisible mit dem Wert true hinzu:

{
  "captcha_type": "PopularCaptchaTaskProxyless",
  "site_key": "10000000-ffff-ffff-ffff-000000000001",
  "site_url": "https://example.com/login",
  "is_invisible": true
}

Sende sie mit deinem Schlüssel im Header Authorization: Bearer, wie in allen anderen Beispielen. Der Aufruf blockiert, bis das Token bereit ist, ohne Polling. Verwende ein Timeout von etwa 185 Sekunden.

Das Token zurückgeben

Integrationen mit unsichtbaren Captchas verwenden fast immer einen Callback statt eines Formularfelds. Die Seite übergibt einen Funktionsnamen an das Widget, entweder im Attribut data-callback oder in den Optionen für render(). Rufe diese Funktion mit dem Token auf, und der eigene Code der Seite läuft weiter, als hätte der Besucher die Prüfung bestanden:

await page.evaluate((t) => {
  document.querySelectorAll('[name="h-captcha-response"]').forEach((el) => { el.value = t; });
  const cb = document.querySelector("[data-sitekey]")?.dataset.callback;
  if (cb && typeof window[cb] === "function") window[cb](t);
}, token);

Das versteckte Feld zusätzlich zu setzen schadet nicht, und es deckt Seiten ab, die das Feld beim Absenden auslesen.

Das Timing ist wichtiger als sonst

Bei einem unsichtbaren Widget entscheidet die Seite, wann die Prüfung läuft, und das ist meist der Moment, in dem der Besucher absendet. Löse deshalb genau in diesem Moment, nicht früher. Am einfachsten ist es, den Solve direkt vor dem Klick in deinem Skript auszulösen, dann den Callback aufzurufen und abzusenden.

Tokens laufen innerhalb von etwa zwei Minuten ab. Ein Token, das beim Laden der Seite geholt und eine Minute später verwendet wird, wird wahrscheinlich abgelehnt.

Häufiger Fehler

Einen unsichtbaren Sitekey als normale sichtbare Aufgabe zu senden kann ein Token erzeugen, das die Seite ablehnt. Wenn die API ein Token zurückgibt, die Seite es aber ablehnt, prüfe der Reihe nach:

Ist is_invisible auf true gesetzt?
Ruft die Seite den Callback auf, und tut sie das, bevor das Formular absendet?
Ist die site_url die Seite, auf der das unsichtbare Widget läuft?
Lehnt die Seite das Token trotzdem ab, kann das Problem an der IP-Adresse hängen, mit der es gelöst wurde. Vergleiche dazu Proxy gegen proxyless lösen.

Einen unsichtbaren Ablauf sicher testen

Unsichtbare Widgets sind von Hand schwer zu testen, weil die Prüfung nur beim Absenden läuft und sie meist ohne sichtbare Anzeige besteht. Teste in dieser Reihenfolge:

Bestätige, dass der Solve ein Token mit is_invisible auf true liefert, mit dem Smoke-Test aus dem Leitfaden zum kostenlosen Test.
Rufe den Callback der Seite selbst in der Browser-Konsole mit diesem Token auf und beobachte, ob das Formular weitergeht.
Sende das Formular aus deinem Skript ab und prüfe die folgende Seite.
Wiederhole den Lauf, wenn möglich, aus einem zweiten Netzwerk, um zu bestätigen, dass das Token nicht an die IP gebunden ist, die es gelöst hat.

Führe den Test nur auf einem Formular aus, das dir gehört, oder auf einer Staging-Kopie der Seite, die du testen darfst. Führe einen unsichtbaren Ablauf niemals gegen ein Live-Konto aus, das nicht dir gehört.

Die Reihenfolge der Ereignisse bei einem unsichtbaren Absenden

Eine funktionierende Integration folgt dieser Abfolge:

Der Besucher oder dein Skript füllt das Formular aus.
Dein Skript liest den Sitekey und die Seiten-URL aus der Seite.
Dein Skript ruft den Solve-Endpunkt mit is_invisible auf true auf und wartet auf das Token.
Dein Skript schreibt das Token in das Antwortfeld und ruft den Callback der Seite auf.
Der Code der Seite sendet das Formular mit dem angehängten Token ab.

Wenn Schritt 3 deutlich früher passiert als Schritt 5, kann das Token ablaufen, bevor das Formular absendet. Halte die Lücke so kurz wie möglich.

Wenn die Seite ein unsichtbares Token ablehnt

Eine Ablehnung liegt nicht immer am Token. Prüfe diese Punkte, bevor du die Solve-Anfrage änderst:

Der Callback lief, bevor das Formular absendete, nicht danach.
Das Formular liest das Token aus dem Feld, in das dein Skript geschrieben hat. Manche Seiten nutzen für unsichtbare Widgets ein anderes Feld.
Die Anfrage mit dem Token kam aus derselben Sitzung, die die Seite geladen hat. Cookies aus einer anderen Sitzung passen nicht.
Die Seite wurde zwischen Solve und Absenden nicht neu geladen, denn das hätte das Token verworfen.

Erst nach diesen Prüfungen solltest du die Proxy-Frage angehen. Die meisten Ablehnungen kommen vom Callback oder von der Sitzung, nicht von der IP.

Nächste Schritte

Starte mit kostenlosem Testguthaben, ohne Karte: Konto erstellen und teste einen unsichtbaren Sitekey auf einer Seite, die dir gehört.