Si vous installez un plugin « Last Login » et que, soudainement, votre écran Utilisateurs WordPress semble organisé, cette netteté vous trompe. Les dates paraissent faisant autorité. Vous pouvez les trier. Elles ressemblent à des faits concrets. Ce n'en sont pas. WordPress n'a jamais stocké de date de dernière connexion native, et chaque valeur dans cette colonne est un artefact d'une mémoire sélective.
L'histoire qui n'a jamais existé
WordPress conserve les comptes dans une table users simple. Il stocke les noms, les e-mails, les hachages de mots de passe et les dates d'inscription. Il manque de manière flagrante tout champ enregistrant la date de la dernière authentification. Cela a toujours été le cas.
Lorsque vous installez un plugin pour combler cette lacune, celui-ci s'accroche au processus de connexion et écrit un horodatage dans les métadonnées de l'utilisateur. C'est tout le mécanisme. Il ne remonte pas dans vos journaux de serveur (logs) et ne reconstruit pas les sessions précédentes. Il commence simplement à surveiller à partir du moment où vous l'activez.
Imaginez un site qui fonctionne depuis cinq ans. Des centaines d'éditeurs, d'abonnés et de prestataires se sont connectés durant cette période. Vous installez un plugin de suivi un mardi après-midi. Le mercredi matin, un rédacteur en chef se connecte. Le plugin enregistre l'heure et la date. Mais votre propre compte administrateur n'affiche rien, car vous ne vous êtes pas connecté depuis l'installation. Un ancien compte de freelance de 2021 n'affiche rien non plus. La colonne donne l'impression qu'aucun de vous n'a jamais touché au site. En réalité, l'enregistrement n'avait tout simplement pas de passé. Il traite l'absence de données comme une preuve d'absence, ce qui est une hypothèse dangereuse lorsque vous gérez des accès.
Trois façons dont la colonne vous induit en erreur
Une fois le plugin en cours d'exécution, l'illusion passe d'une absence d'historique à un rapport au présent corrompu. Il existe trois pièges spécifiques.
Il suit l'authentification, pas l'activité
Lorsqu'un utilisateur coche « Se souvenir de moi » sur l'écran de connexion WordPress, le navigateur reçoit un cookie d'authentification qui peut rester valide jusqu'à quatorze jours. Pendant cette fenêtre, l'utilisateur peut ouvrir le tableau de bord, publier des articles, modérer des commentaires et mettre à jour les paramètres sans jamais retaper de mot de passe. Sa session est vivante et active.
La plupart des plugins de dernière connexion écoutent cependant l'action wp_login. Cette action ne se déclenche que lorsque les identifiants sont soumis via le formulaire, et non lorsqu'une session existante est rafraîchie. Ainsi, votre éditeur pourrait se connecter un lundi matin, maintenir la session du navigateur active et travailler dans la zone d'administration tous les jours pendant deux semaines consécutives. La colonne indiquerait toujours une date vieille de quatorze jours. Un examen de sécurité basé sur cet horodatage marquerait le compte comme inactif. Il ne l'est pas du tout. Vous regardez le moment où un mot de passe a été saisi, et non le moment où un être humain est entré pour la dernière fois chez vous.
Il cache les comptes dormants lors des audits
La plupart des plugins implémentent la colonne triable en joignant la table users à la table usermeta. Structurellement, cela fait sens. Pratiquement, cela crée un bug de visibilité.
Si un utilisateur ne s'est jamais authentifié depuis l'activation du plugin, il n'y a tout simplement aucune ligne dans usermeta pour cette clé. Lorsque vous triez la liste des utilisateurs par « Dernière connexion » pour trouver vos comptes les plus anciens, la requête sous-jacente exclut souvent les utilisateurs qui n'ont pas les métadonnées. Ils disparaissent complètement de la vue triée.
Vous lancez un audit de nettoyage. Vous triez par ordre décroissant et voyez quarante utilisateurs avec des dates de plus en plus anciennes. Vous identifiez avec confiance un groupe à désactiver. Mais vous n'avez jamais vu les dix comptes de prestataires qui sont restés silencieux pendant huit mois parce qu'ils n'ont jamais déclenché le tracker. Ces comptes n'apparaissent pas dans la liste triée, ils n'apparaissent donc pas dans vos conclusions. Votre audit supprime littéralement ses propres résultats. Sur les sites d'adhésion, les plateformes d'e-learning ou les réseaux multisites, cela est particulièrement troublant car les comptes dormants sont souvent les premières cibles des attaquants.
Les données n'existent que lorsqu'elles sont inutiles
Il y a une ironie discrète ici. Le cœur de WordPress (WordPress core) sait quelque chose sur les sessions utilisateur. Lorsqu'une personne se connecte, le système génère des jetons de session et les stocke dans les métadonnées de l'utilisateur. Un administrateur peut voir les sessions actives et les interrompre. Mais cette connaissance est strictement en temps réel. Dès que l'utilisateur clique sur déconnexion, ou que la session expire d'elle-même, WordPress supprime le jeton. L'enregistrement s'évapore.
Vous pouvez voir qui est en ligne en ce moment. Vous ne pouvez pas facilement voir qui était en ligne hier à dix heures du matin. L'architecture a été conçue pour la gestion de session en temps réel, et non pour l'historique