Cette fois on s’intéresse à la mise à la corbeille d’un article. On a vu dans l’article précédent que l’URL de mise à la corbeille est de la forme :
https://alain.arditi.fr/wp-admin/post.php?post=809&action=trash&_wpnonce=feaf2f87fd
Ce lien contient l’identifiant de l’article, ici 809 et un nonce qui vient de la page qui affiche les articles https://alain.arditi.fr/wp-admin/edit.php
Nous allons extraire le nonce depuis la page 482 – /wp-admin/edit.php de notre scénario en passant par un BeanShell PostProcessor qui permet de rajouter l’id_article dans l’expression régulière.
On construit une variable s qui contient l’expression régulière qu’on va passer dans RegPhrase qui sera utilisée dans le « Regular Expression Extractor » :
String s = "post=${id_article}&action=trash&_wpnonce=([^\"]+)\"";
vars.put("RegPhrase",s);
Notez qu’il faut protéger les "
qui font partie de l’expression régulière avec un \
: ([^\"]+)\"
Dans le « Regular Expression Extractor » on retrouve cette fois la variable RegPhrase qui contient notre expression régulière variable
Maintenant qu’on a le « nonce » pour supprimer l’article, on peut l’utiliser dans la page de suppression
Afin de finaliser un scénario complet avec le vidage de la corbeille et le logout, voici les différents « nonces » à extraire et leur utilisation
Nonce pour la santé du site
Ce « nonce » est utilisé dans les requêtes Ajax qui permettent d’avoir l’état de santé du site : le health check site status.
Il est posé sur la page de login /wp-login.php
, une fois qu’on est authentifié et il est utilisé dans les requêtes de la forme /wp_admin/admin-ajax.php
pour avoir l’état de santé du site.
L’expression régulière pour l’extraire est : "site_status_result":"([^"]+)"
Nonce pour le battement de coeur
C’est le « nonce » qui permet de vérifier la légitimité de nos actions sur les articles de WordPress. Il est posé dans la page qui affiche tous les articles /wp-admin/edit.php
et il est utilisé dans les requêtes de la forme /wp_admin/admin-ajax.php
. Si le « nonce » n’est pas correct, WordPress considère qu’on n’est plus authentifié et renvoie des codes « 403 Forbidden » sur les requêtes Ajax. Sur les autres pages on reçoit un code 200, mais c’est la page de login qui s’affiche. D’où l’intérêt d’ajouter des assertions qui vérifient que les réponses à nos requêtes sont bien celles qu’on attend.
L’expression régulière pour l’extraire est : {"nonce":"([^"]+)"}
Nonce de création d’un article
Ce « nonce » est généré lorsqu’on crée un article, sur l’URL /wp-admin/post-new.php
, et il est utilisé dans toutes les requêtes qui suivent la création jusqu’à la publication de l’article.
L’expression régulière pour l’extraire est : wp.apiFetch.createNonceMiddleware\( "([^"]+)" \)
Nonce de déverrouillage de l’article
Ce « nonce » est généré lorsqu’on crée un article, sur l’URL /wp-admin/post-new.php
, et il est utilisé lorsqu’on publie l’article sur une URL /wp_admin/admin-ajax.php
L’expression régulière pour l’extraire est : "unlockNonce":"([^"]+)"
Dans la requête précédente, on voit qu’on passe un paramètre active_post_lock qui vaut 1614277890:1
. Cette valeur est le timestamp de création de l’article au format Epoch suivi de l’identifiant de l’utilisateur. Pour afficher le timestamp au format date, il faut lancer la commande suivante dans un Shell :
1 2 3 |
aa2@apollo:~$ date -r 1614277890 Thu Feb 25 19:31:30 CET 2021 aa2@apollo:~$ |
La variable prédéfinie ${__time(/1000,)} fournit le timestamp à la seconde.
Nonce de vidage de la corbeille
On récupère ce « nonce » dans la page /wp-admin/edit.php
et on l’utilise dans la même page /wp_admin/edit.php
mais avec l’action « Vider la corbeille ».
L’expression régulière pour l’extraire est :<input type="hidden" id="_wpnonce" name="_wpnonce" value="([^"]+)" />
Nonce de déconnexion
C’est le nonce qu’il faut fournir pour terminer sa session proprement. On le récupère sur la page /wp-admin/edit.php
et on l’utilise sur /wp-admin/login.php
L’expression régulière pour l’extraire est :action=logout&_wpnonce=([^']+)'>Se
En plus des « nonces » ci dessus, on avait déjà extrait l’identifiant de l’article dans l’article précédent : Les tests de charge avec JMeter 4/4. Ce qui fait au total 8 « nonces » ou variables pour un scénario qui est très simple. Ce scénario n’a pas d’intérêt en soi, il permet d’illustrer la création de scénarios sur des pages dynamiques. WordPress est un bon exemple car on voit ici que le scénario nécessite pas mal de travail pour fonctionner parfaitement.
Un point à noter, c’est la dépendance du scénario avec le site à tester. Dans le cas de ce WordPress, on a des URLs qui dépendent de certains plugins. L’URL /wp-json/contact-form-7/v1/contact-forms
se retrouve dans le scénario car il y a le plugin Contact Form 7, même si on ne l’utilise pas.
Dans les expressions régulières on est parfois contraint par la locale du site. Si on a plusieurs locales, il faut trouver des expressions régulières indépendantes de la locale.
Tout ceci montre la relative fragilité des scénarios. Il est possible qu’avec une nouvelle version de WordPress le scénario actuel ne fonctionne plus. Pareil si j’ajoute des plugins, ou que je change de langue.
Le bilan est que maintenir un scénario dans la durée est compliqué et nécessite un investissement constant sans quoi si on s’y remet une fois par an on repart de zéro à chaque fois !