La session ne survit pas entre deux appels

Le symptôme. Vous découpez une tâche en deux appels. Le premier se connecte et enregistre la session ; le second la réutilise. Soit le second appel tombe sur la page de connexion, soit, pire, il renvoie vite succes: true sans rien changer sur la cible.

Ce qui se passe

Une session enregistrée est un storage_state de Playwright : les cookies et le stockage local, rien d’autre. Deux choses n’y figurent pas, et ce sont les deux qui font échouer la tâche.

L’état de la page. Une case cochée, une option choisie, une boîte de dialogue ouverte : tout disparaît à la reprise. La page revient vierge, votre scénario s’exécute dessus, clique sur ce que le sélecteur trouve désormais et annonce un succès. Rien n’échoue, du point de vue de Dinoer : le sélecteur a trouvé quelque chose.

La session côté serveur. Beaucoup d’applications attribuent un nouvel identifiant de session juste après la connexion. Si le cookie enregistré date d’avant ce changement, il est valide côté navigateur et inutile côté serveur.

La règle

Ne découpez jamais une tâche qui dépend de l’état de la page. Connexion, action et vérification en un seul appel, quitte à se reconnecter.

Un appel accepte une liste d’actions ; c’est à cela que sert la liste :

{"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"}
 ]}

Un démarrage du navigateur, une réponse. Découpée en plusieurs appels, la même tâche démarre le navigateur et recharge la session à chaque fois, et perd l’état de la page entre deux.

Quand enregistrer la session est le bon outil

Enregistrer une session a un seul usage, étroit : lire plusieurs pages connectées qui ne dépendent pas les unes des autres. Un tableau de bord, puis une page de réglages, puis un rapport, chacun complet en lui-même.

# Se connecter une fois
/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

# Lire autant de pages indépendantes que nécessaire
/opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url https://target.local/dashboard --guide-version 1.6 \
  --reprendre-session ~/session.json

La session porte qui vous êtes, pas ce que vous étiez en train de faire.

Lire la réponse, pas seulement le verdict

Après --reprendre-session, la réponse vous dit où vous en êtes :

"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 apparaît quand la page d’arrivée n’est pas celle sur laquelle la session a été enregistrée : ce que contenait cette page est perdu. Il apparaît aussi quand vous reprenez volontairement sur une autre page ; comparez donc url_courante avec l’adresse demandée. Si vous êtes arrivé sur la page de connexion, la session ne tient plus : reconnectez-vous, sans --reprendre-session. --auth-indicator, avec un sélecteur qui n’existe qu’une fois connecté, répond directement à la question dans auth_status.

Lisez ensuite dernier_code_http. Une session expirée et une erreur de l’application peuvent toutes deux aboutir à la page de connexion. Un 200 ou un 302 indique une expiration : reconnectez-vous. Un 500 ou un 4xx signifie que l’application a échoué et que la session n’était pas en cause ; se reconnecter n’y changera rien.

Sur une exécution qui compte plusieurs actions naviguer, ce champ reflète la dernière navigation seulement, qui n’est pas forcément celle qui explique le problème.

En bref

• Une tâche qui dépend de l’état de la page : un appel, une liste d’actions.
• Lire des pages connectées indépendantes : enregistrer la session convient.
• Après une reprise : comparez url_courante avec la page demandée, puis lisez dernier_code_http.
• Un succes: true rapide sur une tâche que vous pensiez lente est un avertissement, pas un résultat.