Anwendungsbereich: Dieser Leitfaden richtet sich ausschließlich an eigene oder ausdrücklich autorisierte QA-, Staging- und Produktionsumgebungen. Beschrieben werden Diagnose-, Test- und Beobachtungsmuster für Ihre eigene CAPTCHA-Integration – nicht für fremde Websites oder unautorisierte Workflows.
Kurz gesagt: Wer Browser-Sitzungen zwischen Läufen erhält, spart in eigenen QA-Pipelines Anmeldungen, verringert sichtbare CAPTCHA-Abfragen für wiederkehrende Nutzer und ruft CaptchaAI seltener auf. Persistenz ist damit weniger eine Frage der Zuverlässigkeit einzelner Lösungen als eine Frage von Teststabilität und Kosten. Dieser Artikel zeigt, wie Sie Cookies serialisieren, Browser-Profile in CI wiederverwenden und den CAPTCHA-Aufruf auf die Fälle beschränken, in denen Ihre Anwendung tatsächlich eine Abfrage anzeigt.
Wann sich persistente Browser-Sitzungen in eigenen Anwendungen lohnen
Eine frisch gestartete Sitzung ohne Cookies beginnt jedes Mal beim Login. Das ist selten ein Fehler, kostet in wiederholten Testläufen aber Zeit und unnötige Lösungen. Persistente Sitzungen zahlen vor allem an drei Stellen ein:
- Nutzererfahrung in der eigenen App: Wiederkehrende Nutzer bleiben angemeldet und sehen seltener eine sichtbare Abfrage.
- Deterministische QA: Mehrschrittige Test-Suiten – etwa ein Checkout-Flow in Shopware oder ein mehrstufiges Formular – laufen reproduzierbarer, wenn der angemeldete Zustand erhalten bleibt.
- Weniger CAPTCHA-Aufrufe pro Lauf: Jeder gesparte Login ist eine Abfrage weniger, die gelöst werden muss.
| Strategie | Wann sinnvoll |
|---|---|
| Frisches Profil pro Lauf | Reproduzierbare Smoke-Tests mit klarer Fehlerursache |
| Persistentes Profil pro Suite | Mehrschritttests mit möglichst wenigen Anmeldungen |
| Zentraler Profil-Snapshot | Tests starten mit definiertem Cookie-Stand |
Cookies aus eigenen Test-Suiten serialisieren
Für Selenium- oder Playwright-Tests gegen Ihre eigene Anwendung lassen sich Cookies nach erfolgreichem Login auf die Festplatte schreiben und in späteren Schritten wiederherstellen. Das reduziert Anmelde-CAPTCHAs und macht die Läufe deterministischer. Wichtig: Navigieren Sie zuerst auf die Ziel-Domain, bevor Sie Cookies wieder einspielen – sonst weist der Browser sie zurück.
import json
from pathlib import Path
from selenium import webdriver
STORE = Path('./qa-sessions/checkout.json')
def save_session(driver):
STORE.parent.mkdir(parents=True, exist_ok=True)
STORE.write_text(json.dumps(driver.get_cookies()))
def load_session(driver, base_url):
if not STORE.exists():
return False
driver.get(base_url)
for cookie in json.loads(STORE.read_text()):
driver.add_cookie(cookie)
return True
Für den Anfang genügt ein Cookie-Set pro Test-Konto. Wenn Sie mehrere Konten parallel abbilden, legen Sie pro Konto eine eigene Datei an, damit sich die Sitzungen nicht überschreiben.
Persistente Browser-Profile in CI-Pipelines
Headless-Chrome unterstützt einen --user-data-dir, in dem Cookies, localStorage und Permissions zwischen Läufen erhalten bleiben. Das ist die vollständigere Variante: Sie sichern nicht nur einzelne Cookies, sondern den kompletten Profilzustand. In eigenen CI-Pipelines – ob GitLab CI auf einem Hetzner-Runner oder GitHub Actions – empfiehlt sich ein eigenes Verzeichnis pro Test-Suite, damit sich verschiedene Suiten nicht gegenseitig stören.
Zwei Punkte aus der Praxis: Persistente Profile gehören in einen zwischengespeicherten CI-Cache, nicht ins Repository. Und wenn ein Lauf abgebrochen wird, bleibt gelegentlich eine SingletonLock-Datei im Profil zurück – entfernen Sie sie vor dem nächsten Start, sonst startet Chrome nicht.
CaptchaAI nur bei echten CAPTCHA-Abfragen aufrufen
Bleibt die Sitzung erhalten, müssen Sie CaptchaAI nur dann aufrufen, wenn Ihre Anwendung tatsächlich eine Abfrage anzeigt. Eine einfache Bedingung auf das reCAPTCHA-Element genügt, um den Solve-Aufruf zu überspringen, solange kein CAPTCHA im DOM steht:
def maybe_solve(driver, sitekey, page_url):
if driver.find_elements('css selector', '.g-recaptcha'):
token = captchaai_solve(sitekey, page_url)
driver.execute_script(
"document.getElementById('g-recaptcha-response').value = arguments[0];",
token,
)
Das wirkt sich direkt auf Ihre Thread-Auslastung aus. CaptchaAI rechnet pro gleichzeitigem Thread ab – nicht pro Lösung – und jeder Tarif enthält unbegrenzt viele Lösungen pro Thread und Monat. Schon der BASIC-Tarif (15 $/Monat, 5 Threads) deckt eine parallele Test-Suite ab; wer breiter parallelisiert, greift zu STANDARD (30 $/Monat, 15 Threads) oder ADVANCE (90 $/Monat, 50 Threads). Weniger überflüssige Aufrufe bedeuten hier vor allem: mehr freie Threads für die Läufe, die eine Abfrage wirklich enthalten. Für die Token-Übermittlung gelten die üblichen Regeln je Typ – Details unter reCAPTCHA v2 per API lösen und Cloudflare Turnstile per API lösen.
Sitzungsdaten wie Secrets behandeln – DSGVO im Blick
Cookies und Profilverzeichnisse enthalten echte Anmeldeinformationen Ihrer Test-Konten, häufig auch IP-Adressen und andere Daten mit Personenbezug. Nach DSGVO sind IP-Adressen personenbezogene Daten – prüfen Sie Ihre Datenflüsse und die Rechtsgrundlage, wenn solche Artefakte über CI-Systeme oder Backups wandern. Praktisch heißt das:
- Getrennte Speicher pro Umgebung, keine Vermischung von Staging- und Produktionssitzungen.
- Verschlüsselung im Ruhezustand für abgelegte Profile und Cookie-Dateien.
- Regelmäßiges Löschen alter Snapshots und Aufnahme in Ihr Löschkonzept.
Häufige Stolpersteine bei der Sitzungspersistenz
| Symptom | Ursache | Lösung |
|---|---|---|
| Cookies werden nicht übernommen | Domain vor add_cookie nicht aufgerufen |
Erst driver.get(base_url), dann Cookies einspielen |
| Profil lässt sich nicht öffnen | Vorheriger Chrome-Prozess nicht sauber beendet | SingletonLock im Profil entfernen, Prozesse beenden |
| Sitzung gilt trotz Cookies als abgelaufen | sameSite-Feld passt nicht |
Feld vor dem Laden bereinigen oder korrekt setzen |
localStorage bleibt leer |
Falscher Origin beim Wiederherstellen | Storage erst nach Navigation auf den richtigen Origin schreiben |
FAQ
Warum werden meine Cookies erst nach dem Seitenaufruf übernommen?
Weil ein Cookie an seine Domain gebunden ist. add_cookie funktioniert erst, wenn der Browser bereits auf der passenden Domain steht. Rufen Sie deshalb immer zuerst driver.get(base_url) auf und spielen Sie erst danach das gespeicherte Set ein.
Gehören persistente Profile ins Git-Repository?
Nein. Ein --user-data-dir enthält echte Anmeldedaten und wächst schnell. Legen Sie es in den CI-Cache (etwa als GitLab-CI-Artefakt oder Actions-Cache) und behandeln Sie es wie ein Secret – verschlüsselt und mit Ablaufdatum, nicht versioniert.
Muss ich pro Test-Konto eine eigene Sitzung speichern?
Ja, wenn Sie mehrere Konten parallel testen. Ein gemeinsames Cookie-Set würde sich gegenseitig überschreiben. Legen Sie pro Konto eine eigene Datei oder ein eigenes Profilverzeichnis an, damit die Läufe unabhängig bleiben.
Reduziert Sitzungspersistenz die CaptchaAI-Kosten?
Indirekt. Weniger sichtbare Abfragen bedeuten weniger Solve-Aufrufe pro Lauf und damit freiere Threads. Erscheint eine echte Abfrage, löst CaptchaAI sie wie gewohnt – die Persistenz senkt lediglich, wie oft das nötig ist.
Verwandte Leitfäden
- CaptchaAI Schnellstart
- CAPTCHA-QA in autorisierten Testumgebungen
- reCAPTCHA v2 per API lösen
- Cloudflare Turnstile per API lösen
Stabilere CAPTCHA-Workflows in Ihrer eigenen Anwendung – Holen Sie sich Ihren CaptchaAI-Schlüssel.
