ReportedIP Hive 2.0.22 — Hide-Login Sensor, interface utilisateur en allemand et connexion 2FA plus fluide

juin 2, 2026 Updated août 6, 2026 Patrick Schlesinger

ReportedIP Hive 2.0.22 est la version phare parmi les cinq mises à jour publiées depuis la version 2.0.16 : un nouveau capteur « Hide-Login », une interface entièrement en allemand et un processus de Login par authentification à 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 des mises à jour intégrée, effectuée 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 manuellement la vérification via Dashboard → Mises à jour.

Nouveautés de ReportedIP Hive 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 mentionnée ci-dessous correspond à une version officialisée sur GitHub.

2.0.17 — Les blocages liés à l’application de l’authentification à deux facteurs (2FA) ne sont plus présentés à tort comme des « identifiants non valides ».
2.0.19 — Traduction en allemand, correction d’une erreur fatale sous PHP 8 dans l’onglet des paramètres de l’authentification à deux facteurs (2FA) et mise en place d’un contrôle CI visant à garantir l’actualité des traductions.
2.0.20 — Fin des e-mails répétitifs indiquant que « le forfait est actif », simplification de la procédure de mise en place de la 2FA et suppression des codes envoyés par e-mail ou SMS non sollicités.
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 — Le système d’authentification à deux facteurs (2FA) conserve la méthode que vous avez choisie après un code erroné, au lieu de revenir à la méthode précédente.

Le Hide-Login Sensor bloque les analyses visant votre ancienne URL de Login

Si vous utilisez la fonctionnalité « Hide Login » de Hive, votre véritable page de Login se trouve sous 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 : les accès directs répétés à l’ancienne /wp-login.php provenant d’une même adresse IP sont désormais considérés comme un balayage, bloqués selon la même échelle d’escalade que les autres capteurs, et signalés à la communauté.

Une visite accidentelle isolée reste inoffensive : seul le journal de reconnaissance, déjà classé comme « faible gravité », est généré. C’est la répétition d’un schéma qui déclenche le blocage. Le capteur est configurable dans l’onglet « Paramètres de Login » : 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 Whitelist ne sont jamais prises en compte ; votre propre système de surveillance ne déclenchera donc jamais ce blocage.

Cela vient compléter la 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 Hide-Login Sensor détecte les outils de Brute Force qui continuent de bombarder l’URL de Login par défaut.

Le processus de Login avec l’authentification à deux facteurs (2FA) 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, les deux méthodes de réception commencent par une phase de demande : vous sélectionnez la méthode et cliquez sur « Envoyer le code » avant que celui-ci ne soit envoyé. Les méthodes sans état (Authenticator App, Passkey, Recovery Codes) ne sont pas concernées et affichent directement leur champ de saisie.

Conséquence concrète : plus de courriers électroniques ni de SMS indésirables, et aucun dépassement de la Rate Limit ni du quota de relais géré pour une méthode que l’utilisateur n’a pas choisie. Sur une page de Login 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 puis d’en saisir un erroné ou périmé faisait revenir la page directement à l’onglet « E-mail » — la méthode choisie et le code saisi étaient alors tous deux perdus. Le gestionnaire d’erreurs conserve désormais la méthode saisie 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 non valide est rejetée en toute sécurité. Le wp-login.php et le flux front-end de WooCommerce sont pris en charge.

Le sélecteur de méthode n’affiche plus l’abréviation « A…/E…/S…/W… »

Dans la colonne étroite de Login d’une boutique en ligne thématique, les onglets des méthodes se réduisaient auparavant à des 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, afin que les options « Authenticator », « E-mail », « SMS » et « WebAuthn » restent lisibles.

Hive 2.0.19 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, formelle « Sie ») et fournies sous forme de .po / .mo . Les chaînes sources restent en anglais ; WordPress charge automatiquement la traduction allemande lorsque la langue du site est l’allemand, de sorte que toutes les autres locales ne sont pas affectées.

Afin de garantir la fiabilité de cette traduction, cette même version a introduit un contrôle de mise à jour. 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 imprécises, ou que le binaire compilé n’est plus synchronisé. Ce contrôle s’exécute sous forme de tâche CI bloquante, ce qui permet à l’interface utilisateur allemande de rester à jour par rapport à la source à chaque modification. Cette version a également mis à jour l’en-tête « tested-up-to » pour WordPress 7.0.

Corrections concernant le verrouillage, la messagerie électronique et la stabilité

Les blocages liés à la 2FA n’apparaissent plus sous la mention « Identifiants non valides »

Dans la version 2.0.17, un utilisateur contraint qui avait épuisé son quota de contournement de la configuration de la 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 Login permettant l’énumération des utilisateurs. Cela a contraint les administrateurs bloqués à procéder à une réinitialisation inutile de leur mot de passe. Le masque laisse désormais passer les messages relatifs à la 2FA, 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 ou non. 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 transitoire d’une durée de cinq minutes pour déterminer le niveau précédent. Une fois ce statut transitoire expiré, le niveau précédent basculait vers « gratuit » ; ainsi, chaque actualisation ultérieure d’une clé payante détectait à nouveau une transition fantôme de « gratuit » vers « payant » et renvoyait l’e-mail. La version 2.0.20 transforme cette valeur de référence en une option permanente : la première observation l’initialise en arrière-plan et l’e-mail n’est déclenché qu’en cas de véritable changement de niveau. Vérifié en production : aucun déclenchement lors d’actualisations répétées d’un niveau actif, et exactement un déclenchement lors d’un véritable passage à un niveau supérieur.

Petites corrections de précision

2.0.19 — une TypeError sur PHP 8 supprimait l’onglet des paramètres d’authentification à deux facteurs (2FA) et l’étape du Setup Wizard 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 — Le Setup Wizard a supprimé en silence 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 provenant pas de plugins, et le bouton principal perdait son contraste à l’intérieur de WordPress .notice. Une feuille de style autonome est désormais intégrée à chaque écran d’administration.
2.0.20 — L’assistant de configuration guidée 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. L’outil de vérification des mises à jour du plugin interroge GitHub Releases toutes les 12 heures. Si vous ne souhaitez pas attendre, vous pouvez forcer une vérification via Dashboard → 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 Changelog de l’API et des plugins. La configuration, la fonctionnalité « Hide Login » et la configuration de l’authentification à deux facteurs (2FA) sont décrites dans la documentation du plugin WordPress.

Obtenir ReportedIP Hive →