I’m a (script driven) robot

Vous l’avez sans doute compris, j’aime beaucoup le scraping.  Pour des cas compliqués, l’émulation d’un véritable browser devient de plus difficile. Certaines protections vont tellement loin dans construction des requêtes successives pour obtenir un résultat que cela devient pénible et aussi instable.

Je suis donc parti, pour ces cas, dans l’approche Selenium, c’est à dire un véritable navigateur sans tête piloté par script. 

Au final je suis parti parti la sous-branche qui procède à cette construction en utilisant google-chrome (c’est fallacieux et amusant à la fois, sachant que je n’utilise jamais ce navigateur).

Il y a des exemples dans beaucoup de langages, mais finalement assez peu sur les bindings en perl.

Grâce à cet article, https://www.perl.com/article/spidering-websites-with-headless-chrome-and-selenium/ la lumière m’est apparue et j’ai gagné beaucoup. It’s more fun to compute en perl. https://en.perlzemi.com/blog/20211119124656.html est aussi très sympa.

J’ai suivi sa procédure, avec quelques adaptations pour mon Ubuntu server. J’ai pris une version plus récente du chrome driver, installation chrome et module Selenium::Remote::Driver sans problèmes. J’avais sur mon système une version de java (pour mon solr) pas compatible semble t’il avec le serveur selenium standalone. J’ai donc mis un openjdk 11 et tout s’est bien emboité.

C’est assez tranquille mais j’ai pas mal erré pour ce qui est de cacher le caractère headless de mon chrome en écrasant la chaîne user-agent d’origine car sinon c’est pas du jeu. Pour une chaîne user-agent dans une variable $ua, je me retrouve avec le constructeur suivant, avec un peu de random en plus dans la taille de la fenêtre virtuelle:

$sx = sprintf("%d",1600 + ((rand() - rand()) * 303 ));
$sy = sprintf("%d",900 + ((rand() - rand()) * 256 ));
my $driver;
eval {
$driver = Selenium::Remote::Driver->new(
  browser_name => $ua,
  extra_capabilities => {
    chromeSwitches => [ "--user-agent= '$ua'" ],
    chromeOptions => {
      args => [
        'window-size='.$sx.','.$sy,
        'headless',
        'user-agent='.$ua,
      ],
    },
  },
  );
};

A partir de là, j’ai pu réellement jouer. Le driver Selenium permet pas mal de choses, mais, pour le moment, je récupère surtout la source de la page que je passe ensuite à une XML::LibXML comme à mes habitudes des dernières années. Il est possible de jouer avec des XPaths, des screenshots, des evals de javascript donc plein de choses très amusantes en perspective. Cela permet notamment d’obtenir le DOM interprété plutôt que la source de la page $driver->execute_script("return document.documentElement.outerHTML");

Ne pas oublier à la fin de faire un $driver->quit() pour libérer de la mémoire

Dans un browser, ça a l’apparence du web mais ce n’est pas du web

Faites une requête avec le mot « emprise » dans un moteur de recherche type google. Vous obtenez des résultats. C’est sur le web et dans un browser. Mon test pour dire que c’est du web est que c’est modifiable/remixable: par exemple:

document.evaluate('//text()[contains(.,"emprise")]',document.body,null,XPathResult.ORDERED_NODE_SNAPSHOT_TYPE);

Cela retourne des résultats avec lesquels ont peut jouer (console JS/DOM, user scripts, ..etc)

Par contre, si je vais sur docs.google.com, que je crée un document dans lequel je tape juste le mot « emprise », même en faisant attention à la case du texte, je n’obtiens rien avec le test précédent, mis à part un script de données qui contient ce même mot. En clair, il ne trouve pas de nodes textuelles contenant le mot en question. Et pour cause, l’affichage est en fait une balise canvas donc hors du DOM qui est l’essence du web/html. Autant mettre un binaire qui pointerai vers une VM. Ici le web n’est qu’un transport et le browser un simple réceptacle.

Ensuite le site en question trouve malin d’intercepter tous les événements clavier. Tout y passe sauf bien sûr ceux qui sont interceptés auparavant par le browser. Bref, on ne peux pas jouer ici. Ce n’est pas du web, désolé. Mauvais karma.