Administrer une interface web de bout en bout
Le cœur du navigateur conservé effectue toujours des tâches authentiques et complexes en plusieurs étapes — c'est la fonctionnalité que Dinoer a délibérément intégrée, et non un simple hasard.
Ne confondez pas ceci avec l’interface principale de ce projet : il s’agit d’un corpus de recherche verrouillé, et non d’un panneau d’administration. Mais cette fonctionnalité n’a pas disparu lorsque la couche de présentation a été supprimée : rpa.py continue de gérer une interface authentifiée de la même manière qu’une personne le ferait, en plusieurs étapes, après une connexion. C’est utile lorsqu’une campagne de recherche doit s’authentifier pour lire une source protégée ; c’est une fonctionnalité à part entière lorsque la tâche consiste réellement en une configuration, et non en une recherche.
Derrière un défi de base au niveau du réseau
Un serveur cible se trouvant derrière la couche HTTP Basic propre d’un proxy inverse, en plus de son système de connexion applicatif :
{"http_credentials": true, "url": "https://target.local/admin", "actions": [...]}
Le scénario ne révèle toujours aucun secret ; http_credentials indique à Dinoer de
le résoudre à partir du répertoire chiffré, limité à cette origine, le même
mécanisme qu’utilise un champ de formulaire.
Qu’est-ce qui fait que cette solution fonctionne ?
Pour toute opération nécessitant un état, utilisez une seule requête. Connectez-vous, effectuez une action, confirmez, le tout en une seule
invocation. Diviser cela en plusieurs requêtes entraîne la perte silencieuse de l’état du DOM : une session enregistrée ne contient que des cookies et localStorage uniquement, jamais ce qui était affiché à l’écran.
Une affirmation en haut. Si la page n’est pas celle attendue, arrêtez-vous avant de taper quoi que ce soit, n’importe où :
{"type": "evaluer", "script": "document.title", "contient": "Sign in"}
Un répertoire chiffré pour chaque identifiant.
{"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"}
Le scénario reste validé car il utilise des clés, et non des valeurs.
Des signaux lus, pas seulement le verdict. Après chaque étape : où suis-je vraiment (boussole.url_courante), qu’a dit le serveur (boussole.dernier_code_http), la session a-t-elle tenu (session_derive).
Où cela s’arrête
Les opérations qui durent quelques minutes ne fonctionnent pas bien : le cœur conservé renvoie une réponse finale, et non un flux, et un délai d’attente ne signifie pas un échec : le serveur continue de fonctionner après que le client a cessé d’attendre. Les mutations massives sur de nombreux cibles indépendantes sont mieux gérées par campagne.py, ou par une API si elle existe pour la cible. Et rien ici ne peut être annulé : il exécute la liste que vous avez écrite, à la vitesse de la machine.