Communiqués

ReportedIP 2.0.22 — Capteur de connexion masquée, interface utilisateur en allemand et connexion 2FA plus fluide

2 juin 2026 · Patrick Schlesinger

ReportedIP 2.0.22 est la dernière d'une série de cinq mises à jour publiées depuis la version 2.0.16 : elle inclut un nouveau capteur de détection de connexion frauduleuse, une interface entièrement en allemand et un processus de connexion à deux facteurs (2FA) qui n'envoie plus de codes non sollicités. Toutes ces nouveautés sont déployées sur les sites existants via la vérification automatique des mises à jour toutes les 12 heures.

Ce récapitulatif couvre toutes les versions comprises entre la 2.0.17 et la 2.0.22. Les sites configurés pour la mise à jour automatique reçoivent la dernière version dans les douze heures ; pour la télécharger dès maintenant, lancez une vérification manuelle via Tableau de bord → Mises à jour.

Quelles sont les nouveautés de ReportedIP 2.0.22 et des versions précédentes ?

Ce travail s'articule autour de quatre axes : un nouveau capteur de détection des tentatives de connexion, un processus d'authentification à deux facteurs (2FA) plus fluide et plus robuste, une traduction complète en allemand, ainsi qu'une série de corrections concernant les e-mails et la stabilité. Chaque version ci-dessous correspond à une version officialisée sur GitHub.

• 2.0.17 — Les verrouillages liés à l'application de l'authentification à deux facteurs ne sont plus présentés à tort comme des « identifiants non valides ».
• 2.0.19 — Traduction en allemand, correction d'une erreur fatale PHP 8 dans l'onglet des paramètres de l'authentification à deux facteurs (2FA) et mise en place d'un contrôle CI pour garantir l'actualité des traductions.
• 2.0.20 — Fin des e-mails répétitifs indiquant que « le plan est actif », simplification de la procédure d'activation de l'authentification à deux facteurs (2FA) et suppression des codes envoyés par e-mail ou SMS sans demande préalable.
• 2.0.21 — Le capteur « Hide-Login » et le sélecteur de méthode ne sont plus tronqués sur les cartes de connexion étroites.
• 2.0.22 — La procédure d'authentification à deux facteurs conserve la méthode que vous avez choisie après un code erroné, au lieu de revenir à la méthode précédente.

Le capteur Hide-Login bloque les analyses de votre ancienne URL de connexion

Si vous activez la fonctionnalité « Hide Login » de Hive, votre véritable page de connexion se trouve à l'adresse d'un slug personnalisé et /wp-login.php ne devrait jamais être consultée par un visiteur légitime. La version 2.0.21 transforme cela en un signal de détection : des accès directs répétés à l'ancienne /wp-login.php provenant d'une même adresse IP sont désormais considérées comme un balayage, bloquées selon le même processus d'escalade que les autres capteurs, et signalées à la communauté.

Une seule visite accidentelle reste inoffensive : seul le journal de reconnaissance, déjà peu grave, est généré. C'est la répétition de ce schéma qui déclenche le blocage. Le capteur est configurable dans l'onglet « Paramètres de connexion » : un commutateur principal (activé par défaut), un seuil de détection (5 par défaut) et une durée (10 minutes par défaut). Les adresses IP figurant sur la liste blanche ne sont jamais prises en compte, ce qui évite que votre propre système de surveillance ne déclenche le blocage.

Cela vient compléter la fonctionnalité de détection des chemins d'appât abordée dans les notes de mise à jour de la version 2.0.16: les chemins d'appât détectent les tentatives d'accès aux identifiants et aux fichiers de sauvegarde, tandis que le capteur « Hide-Login » détecte les outils de force brute qui continuent de bombarder l'URL de connexion par défaut.

Le processus de connexion avec l'authentification à deux facteurs cesse d'envoyer des codes que vous n'avez jamais demandés

Avant la version 2.0.20, un utilisateur dont la méthode principale était l'e-mail ou le SMS recevait un code à usage unique dès le chargement de l'écran de vérification, avant même de pouvoir choisir une méthode. Désormais, ces deux modes de réception commencent par une phase de demande : vous devez sélectionner la méthode et cliquer sur « Envoyer le code » avant que celui-ci ne soit envoyé. Les méthodes sans état (application d'authentification, clé d'accès, codes de récupération) ne sont pas concernées et affichent directement le champ de saisie.

En pratique : plus de courriers électroniques ni de SMS indésirables, et aucun dépassement de la limite de fréquence ou du quota de relais géré pour une méthode que l'utilisateur n'a pas choisie. Sur une page de connexion très fréquentée, ce quota est crucial — découvrez le fonctionnement des quotas de relais et des e-mails d'alerte à 80 % et 100 % dans les notes de la version 2.0.16.

Le défi consiste désormais à conserver votre méthode après une erreur de code

La version 2.0.22 corrige une boucle frustrante. Lorsque plusieurs méthodes étaient configurées, le fait de passer de l'onglet « E-mail » à l'onglet « SMS », de demander un code et d'en saisir un erroné ou périmé renvoyait immédiatement la page vers l'onglet « E-mail » — la méthode choisie et le code saisi étaient alors tous deux perdus. Le gestionnaire de défis conserve désormais la méthode sélectionnée lors d'un rafraîchissement de la page (vérification échouée, verrouillage temporaire), ce qui vous permet de rester sur votre onglet, de voir l'erreur et de saisir à nouveau le code. La valeur est toujours validée par rapport aux méthodes actives du compte, de sorte qu'une méthode falsifiée est rejetée en toute sécurité. Les deux wp-login.php et le flux de l'interface utilisateur de WooCommerce sont abordés.

Le sélecteur de méthode n'affiche plus les abréviations « A…/E…/S…/W… »

Dans la colonne de connexion étroite de la page d'accueil thématique, les onglets des méthodes s'affichaient auparavant sous forme d'abréviations d'une seule lettre. Le sélecteur s'adapte désormais à la largeur réelle de la carte grâce à une requête de conteneur CSS et empile les méthodes sous forme de liste verticale avec les libellés complets lorsque l'espace est restreint, ce qui permet de conserver la lisibilité des options « Authenticator », « E-mail », « SMS » et « WebAuthn ».

La version 2.0.19 de Hive propose une interface entièrement en allemand

Toutes les chaînes destinées aux utilisateurs — soit environ 1 845 — sont désormais traduites en allemand (de_DE, avec le « Sie » formel) et fournies sous forme compilée .po / .mo paire. Les chaînes source restent en anglais ; WordPress charge automatiquement la traduction allemande lorsque la langue du site est l'allemand, de sorte que les autres paramètres régionaux ne sont pas affectés.

Afin de garantir la fidélité de cette traduction, ce même communiqué a introduit un « filtre de fraîcheur ». composer i18n:check La compilation échoue lorsque le modèle de traduction est obsolète, que le fichier allemand contient des entrées non traduites ou incertaines, ou que le binaire compilé n'est plus synchronisé. Elle s'exécute sous forme de tâche CI bloquante, ce qui permet à l'interface utilisateur allemande de rester à jour par rapport au code source à chaque modification. Cette version a également mis à jour l'en-tête « tested-up-to » pour WordPress 7.0.

Corrections concernant les blocages, les e-mails et la stabilité

Les blocages liés à l'authentification à deux facteurs ne s'affichent plus sous la forme « Identifiants non valides »

Dans la version 2.0.17, un utilisateur contraint qui avait épuisé son quota de contournement de la configuration de l'authentification à deux facteurs (2FA) voyait la raison réelle — « Authentification à deux facteurs requise — quota de contournement épuisé, contactez un administrateur » — remplacée par le message générique « Identifiants non valides » par le masque de connexion de l'énumération des utilisateurs. Cela a conduit les administrateurs bloqués à effectuer une réinitialisation de mot de passe inutile. Le masque laisse désormais passer les messages relatifs à l'authentification à deux facteurs, car ce blocage ne se déclenche qu'après la validation du mot de passe ; ainsi, l'affichage de la raison ne révèle en rien si le nom d'utilisateur existe. Les véritables erreurs d'identifiants restent masquées.

Fini les e-mails répétitifs indiquant que « le forfait est actif »

L'e-mail de bienvenue en cas de changement de niveau se basait auparavant sur un état temporaire valable cinq minutes pour déterminer le niveau précédent. Une fois ce délai écoulé, le niveau précédent passait automatiquement à « gratuit » ; par conséquent, chaque actualisation ultérieure d'une clé payante détectait à nouveau une transition fantôme de « gratuit » à « payant » et renvoyait l'e-mail. La version 2.0.20 fait de cette base de référence une option permanente : la première observation l'initialise silencieusement et l'e-mail n'est envoyé qu'en cas de véritable changement de niveau. Vérifié en production : zéro envoi lors d'actualisations répétées d'un niveau actif, et exactement un envoi lors d'une véritable mise à niveau.

Petites corrections de bugs

• 2.0.19 — a TypeError Sous PHP 8, l'onglet des paramètres de l'authentification à deux facteurs (2FA) et l'étape de l'assistant de configuration étaient désactivés lorsque les options `enforce-roles` ou `allowed-methods` étaient stockées sous forme de tableau. Les lectures passent désormais par une fonction d'aide tolérante au format.
• 2.0.20 — L'assistant de configuration a supprimé en arrière-plan les rôles « enforced-2FA » dont le slug n'était pas en minuscules (rôles du plugin « membership » tels que um_Premium-Member) ; il conserve désormais le slug, conformément à l'onglet des paramètres.
• 2.0.20 — Les notifications d'administration n'étaient pas mises en forme sur les écrans d'administration ne relevant pas d'un plugin, et le bouton principal perdait son contraste à l'intérieur d'un WordPress .notice. Une feuille de style autonome est désormais intégrée à chaque écran d'administration.
• 2.0.20 — L'assistant de configuration de l'authentification à deux facteurs (2FA) est désormais accessible directement depuis la bannière de recommandation et la section 2FA du profil, et l'assistant lui-même a été simplifié.

Comment passer à la version 2.0.22

• Mise à jour automatique intégrée au plugin. Le Plugin Update Checker interroge GitHub Releases toutes les 12 heures. Si vous ne souhaitez pas attendre, lancez une vérification manuelle via Tableau de bord → Mises à jour.
• Téléchargement manuel. Téléchargez le fichier ZIP de la version 2.0.22 sur GitHub.
• WP-CLI. wp plugin update reportedip-hive si vous gérez WordPress depuis la ligne de commande.

Pour en savoir plus sur la version précédente et consulter l'historique complet des versions, consultez les notes de mise à jour de la version 2.0.16 ainsi que le journal des modifications de l'API et des plugins. La configuration, la fonctionnalité « Masquer la connexion » et la configuration de l'authentification à deux facteurs (2FA) sont décrites dans la documentation du plugin WordPress.

Obtenir ReportedIP →