Die Sitzung bleibt zwischen zwei Aufrufen nicht erhalten

Das Symptom. Sie teilen einen Ablauf auf zwei Aufrufe auf. Der erste meldet sich an und speichert die Sitzung; der zweite verwendet sie wieder. Entweder landet der zweite Aufruf wieder auf der Anmeldeseite, oder – und das ist schlimmer – er liefert nach etwa einer Sekunde succes: true und ändert nichts am Ziel.

Was tatsächlich passiert

Eine gespeicherte Sitzung ist ein storage_state von Playwright: Cookies und localStorage, sonst nichts. Zwei Dinge sind nicht darin, und genau die bringen Sie zu Fall.

Der DOM-Zustand ist nicht darin. Ein angekreuztes Kontrollkästchen, ein eingestelltes <select>, ein geöffneter Dialog – beim Fortsetzen ist alles weg. Die Seite kommt unberührt zurück. Ihre nummerierten Aktionen laufen dann auf einer frischen Seite, treffen das Element, das jetzt diese Nummer trägt, und melden Erfolg. Kein Fehler, weil aus Sicht von Diwall nichts schiefging: Es hat Element 7 angeklickt, und Element 7 existierte.

Die serverseitige Sitzung ist auch nicht darin. Viele Anwendungen rufen direkt nach der Anmeldung etwas wie session_regenerate_id() auf. Das gespeicherte Cookie ist das von vor der Neuerzeugung. Der clientseitige Schnappschuss ist vollkommen gültig und vollkommen nutzlos.

Die Regel

Teilen Sie einen zustandsbehafteten Ablauf nie auf. Anmelden, handeln und bestätigen in einem einzigen Aufruf, auch wenn das eine erneute Anmeldung bedeutet.

Gemessen an einem echten Ziel: Die Version mit einem Aufruf brauchte 7,5 Sekunden und funktionierte; die aufgeteilte Version brauchte 1,1 Sekunden und tat stillschweigend nichts. Die schnelle ist die, die gescheitert ist.

Ein einzelner Aufruf nimmt ein Array von Aktionen – genau dafür ist das Array da:

diwall-shot --url https://target.local/login --som --guide-version 1.3 \
  --actions '[
    {"type": "remplir_som", "id": 4, "valeur": "depuis_secrets", "secret_cle": "username"},
    {"type": "remplir_som", "id": 5, "valeur": "depuis_secrets", "secret_cle": "password"},
    {"type": "cliquer_som", "id": 7},
    {"type": "attendre_selecteur_present", "selecteur": ".user-menu"},
    {"type": "cliquer_som", "id": 12}
  ]'

Ein Browserstart, eine abschließende Aufnahme. Die aufgeteilte Version kostet pro Aufruf einen Start von Playwright, ein Neuladen des Speichers und eine vollständige Neuberechnung von Set-of-Mark – sie ist pro Schritt langsamer und verliert Ihren Zustand dazwischen.

Wann Persistenz das richtige Werkzeug ist

Sitzungspersistenz ist keine Falle, sondern ein Werkzeug mit engem Zweck: mehrere angemeldete Seiten lesen, die nicht voneinander abhängen. Ein Dashboard, dann eine Einstellungsseite, dann ein Bericht – jede für sich.

# Einmal anmelden
diwall-shot --url https://target.local/login --som --guide-version 1.3 \
  --actions login.json --sauver-session ~/session.json

# So viele unabhängige Seiten lesen, wie Sie wollen
diwall-shot --url https://target.local/dashboard --som --guide-version 1.3 \
  --reprendre-session ~/session.json

Seit 1.11.1 wird die Sitzungsdatei am Ende des Laufs nicht mehr gelöscht, verkettete Aufrufe sind also sicher. Setzen Sie --sauver-session nur dann erneut, wenn Sie den gespeicherten Zustand bewusst auffrischen wollen.

Die Linie, die zu halten ist: Persistenz trägt, wer Sie sind, nicht, was Sie gerade taten.

Die Antwort lesen, nicht nur das Urteil

Jeder Aufruf nach --reprendre-session sagt Ihnen, ob die Sitzung gehalten hat:

"boussole": {
  "session_derive": true,
  "url_courante": "https://target.local/login",
  "dernier_code_http": 302
}

session_derive: true heißt, dass Sie nicht mehr dort sind, wo Sie sich glaubten. Führen Sie die vollständige Anmeldung erneut aus, ohne --reprendre-session.

Lesen Sie danach dernier_code_http, denn zwei sehr verschiedene Fehler sehen identisch aus. Eine wirklich abgelaufene Sitzung und ein hinter display_errors=0 verborgener Anwendungsfehler setzen Sie beide mit session_derive: true auf der Anmeldeseite ab. Ein 302 oder 200 deutet auf einen echten Ablauf hin – melden Sie sich erneut an. Ein 500 oder ein 4xx bedeutet, dass die Anwendung kaputt war und Ihre Sitzung nie das Problem; erneutes Anmelden kostet Sie nur Zeit.

Eine Feinheit: Bei einem Lauf mit mehreren naviguer-Aktionen spiegelt dieses Feld nur die letzte Navigation wider, die nicht unbedingt die ist, die die Abweichung erklärt.

Kurz gesagt

• Zustandsbehaftet – anmelden, handeln, bestätigen: ein Aufruf, ein Array von Aktionen.
• Zustandslos – unabhängige angemeldete Seiten lesen: Persistenz ist in Ordnung.
• Nach jedem Fortsetzen: session_derive prüfen, dann dernier_code_http.
• Ein schnelles succes: true bei einem Ablauf, den Sie langsam erwartet haben, ist eine Warnung, kein Ergebnis.