Die Sitzung überdauert keine zwei Aufrufe

Das Symptom. Sie teilen eine Aufgabe auf zwei Aufrufe auf. Der erste meldet sich an und speichert die Sitzung, der zweite verwendet sie weiter. Entweder landet der zweite Aufruf auf der Anmeldeseite, oder, schlimmer, er liefert schnell succes: true und ändert nichts am Ziel.

Was passiert

Eine gespeicherte Sitzung ist ein storage_state von Playwright: Cookies und lokaler Speicher, sonst nichts. Zwei Dinge fehlen darin, und genau diese beiden lassen die Aufgabe scheitern.

Der Zustand der Seite. Ein gesetztes Häkchen, eine gewählte Option, ein offener Dialog: Beim Fortsetzen ist alles weg. Die Seite kommt leer zurück, Ihr Szenario läuft darauf, klickt auf das, was der Selektor jetzt findet, und meldet Erfolg. Aus Sicht von Dinoer scheitert nichts: Der Selektor hat etwas gefunden.

Die Sitzung auf dem Server. Viele Anwendungen vergeben direkt nach der Anmeldung eine neue Sitzungskennung. Stammt das gespeicherte Cookie von vor diesem Wechsel, ist es im Browser gültig und auf dem Server nutzlos.

Die Regel

Teilen Sie nie eine Aufgabe auf, die vom Zustand der Seite abhängt. Anmelden, handeln und prüfen in einem Aufruf, auch wenn das eine neue Anmeldung bedeutet.

Ein Aufruf nimmt eine Liste von Aktionen; genau dafür ist die Liste da:

{"url": "https://target.local/login",
 "actions": [
   {"type": "remplir", "selecteur": "input[name=\"username\"]", "valeur": "depuis_secrets", "secret_cle": "username"},
   {"type": "remplir", "selecteur": "input[name=\"password\"]", "valeur": "depuis_secrets", "secret_cle": "password"},
   {"type": "cliquer", "selecteur": "button[type=\"submit\"]"},
   {"type": "attendre_selecteur_present", "selecteur": ".user-menu"},
   {"type": "cliquer", "selecteur": "#next-step"}
 ]}

Ein Browserstart, eine Antwort. Auf mehrere Aufrufe verteilt, startet dieselbe Aufgabe jedes Mal den Browser, lädt die Sitzung neu und verliert dazwischen den Zustand der Seite.

Wann das Speichern der Sitzung das richtige Werkzeug ist

Eine Sitzung zu speichern hat einen einzigen, engen Zweck: mehrere Seiten mit Anmeldung lesen, die nicht voneinander abhängen. Ein Dashboard, dann eine Einstellungsseite, dann ein Bericht, jede für sich vollständig.

# Einmal anmelden
/opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url https://target.local/login --guide-version 1.6 \
  --actions login.json --sauver-session ~/session.json

# Beliebig viele unabhängige Seiten lesen
/opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url https://target.local/dashboard --guide-version 1.6 \
  --reprendre-session ~/session.json

Die Sitzung trägt, wer Sie sind, nicht, was Sie gerade taten.

Die Antwort lesen, nicht nur das Urteil

Nach --reprendre-session sagt Ihnen die Antwort, wo Sie stehen:

"boussole": {
  "url_courante": "https://target.local/login",
  "dernier_code_http": 200,
  "session_derive": {"url_sauvegardee": "https://target.local/dashboard",
                     "url_reprise": "https://target.local/login",
                     "avertissement": "…"}
}

session_derive erscheint, wenn die Seite, auf der Sie gelandet sind, nicht die ist, auf der die Sitzung gespeichert wurde: Was diese Seite enthielt, ist verloren. Es erscheint auch, wenn Sie absichtlich auf einer anderen Seite fortsetzen; vergleichen Sie daher url_courante mit der angefragten Adresse. Sind Sie auf der Anmeldeseite gelandet, trägt die Sitzung nicht mehr: Melden Sie sich neu an, ohne --reprendre-session. --auth-indicator mit einem Selektor, der nur nach der Anmeldung existiert, beantwortet die Frage direkt in auth_status.

Lesen Sie dann dernier_code_http. Eine abgelaufene Sitzung und ein Anwendungsfehler können beide auf der Anmeldeseite enden. Ein 200 oder 302 deutet auf einen Ablauf hin: Melden Sie sich neu an. Ein 500 oder ein 4xx heißt, dass die Anwendung versagt hat und die Sitzung nie das Problem war; eine neue Anmeldung hilft nicht.

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

Kurz gesagt

• Eine Aufgabe, die vom Seitenzustand abhängt: ein Aufruf, eine Liste von Aktionen.
• Unabhängige Seiten mit Anmeldung lesen: Sitzung speichern ist in Ordnung.
• Nach einem Fortsetzen: url_courante mit der angefragten Seite vergleichen, dann dernier_code_http lesen.
• Ein schnelles succes: true bei einer Aufgabe, die Sie für langsam hielten, ist eine Warnung, kein Ergebnis.