Skip to main contentSkip to footer
Communiqués de presse

ReportedIP Hive 2.0.16 — E-mails d'alerte concernant le plafonnement de fréquence des promotions et les quotas

Updated Patrick Schlesinger
ReportedIP Hive 2.0.16 release banner showing a 90-day global promo cap, 80% relay quota alert mails and three new notification toggles

La version ReportedIP Hive 2.0.16 regroupe toutes les notifications de mise à jour sous un seuil de fréquence unique, ajoute des e-mails d’alerte concernant le quota de relais à 80 % et 100 %, et corrige une série de bogues liés à la réactivation du Hardening Mode et au recul des relais. Cette version est stable et est distribuée via la vérification des mises à jour intégrée, effectuée toutes les 12 heures.

Les sites configurés pour la mise à jour automatique la recevront dans les douze heures. Pour la récupérer dès maintenant, lancez une vérification manuelle via le Dashboard → Mises à jour ou téléchargez la version balisée depuis GitHub.

Comment le plafond promotionnel unifié modifie Hive 2.0.16 pour les administrateurs du Free tier

Une nouvelle classe, ReportedIP_Hive_Promo_Manager, est désormais la seule source de référence pour déterminer si « cette suggestion de mise à niveau peut s’afficher maintenant ». Toutes les surfaces promotionnelles passent par cette classe : la bannière WooCommerce 2FA, la carte de vente incitative intégrée Frontend 2FA, la carte du Dashboard Mail/SMS Relay et le bloc d’informations sur le Hardening Mode. Avant la version 2.0.16, chacune de ces surfaces disposait de son propre délai d’attente ad hoc et ceux-ci pouvaient se cumuler.

Le responsable applique quatre règles à la fois :

  • Plafond mondial de 90 jours par administrateur, toutes plateformes promotionnelles confondues.
  • Délai d’attente de 60 jours après un licenciement, applicable à chaque fonctionnalité.
  • Désactivation définitive par utilisateur grâce à un lien « Ne plus afficher ce message ».
  • Commutateur d’arrêt dans « Paramètres » → « Notifications » qui masque d’un seul coup toutes les suggestions de mise à jour.

Résultat net : un administrateur de l’offre Free tier ne voit au maximum qu’environ quatre messages promotionnels distincts par an. Cette mise à jour a également supprimé une carte de vente incitative en double concernant le Frontend 2FA, qui n’avait pas sa place dans l’onglet « Hardening Mode », et a prolongé le Two_Factor_Recommend délai de réapparition de la bannière souple de 30 minutes à 14 jours. Le parcours d’intégration à blocage strict pour les rôles privilégiés reste inchangé : une recommandation de sécurité prime toujours sur le confort.

Les alertes relatives aux quotas de relais vous sont désormais envoyées par e-mail

Une nouvelle ReportedIP_Hive_Quota_Notifier évalue l’instantané du quota de relais après chaque actualisation cron toutes les six heures. Lorsqu’un canal dépasse 80 % ou 100 % de son quota mensuel, il envoie un e-mail d’information à la liste des destinataires d’alerte. Chaque canal et chaque étape sont soumis à un délai de réinitialisation de 30 jours, qui se réinitialise automatiquement à chaque nouvelle période de facturation (le period_start changement de mois), de sorte qu’un nouveau mois marque le redémarrage des alertes.

Il existe également une fonctionnalité intégrée au Dashboard. Lorsque le Mail Relay ou le SMS Relay renvoie un code HTTP 402 (limite mensuelle) ou 429 (délai d’attente du destinataire/site), le fournisseur appose un reportedip_hive_relay_cap_state_* . Les pages d’administration affichent alors un message d’avertissement non promotionnel — pouvant être masqué pendant 24 heures — expliquant que les e-mails sont actuellement redirigés vers wp_mail() et que l’authentification par SMS (2FA) est suspendue, avec un lien vers les détails du quota. Le prochain /relay-quota qui indique une utilisation inférieure à la limite efface automatiquement cet état.

En cas de modification du plan, envoyez un bref e-mail d’information

Tier_Upgrade::on_tier_changed gère désormais aussi bien les rétrogradations que les mises à niveau. Lors d’une rétrogradation, il efface l’état obsolète de la bannière post-mise à niveau, désactive temporairement le bouton de basculement « WooCommerce Frontend 2FA » — vos données sont conservées afin qu’une nouvelle mise à niveau ultérieure se fasse en toute transparence — et envoie un bref e-mail d’information. Les mises à jour déclenchent l’envoi d’un e-mail de bienvenue correspondant qui indique les étapes de configuration restantes. Ces deux e-mails peuvent être désactivés à l’aide du nouveau bouton situé dans Paramètres → Notifications.

Dans la version 2.0.16, cet onglet « Paramètres » comporte désormais trois boutons : masquer toutes les suggestions de mise à jour (désactivé par défaut — les suggestions restent actives), envoyer un e-mail lorsque le quota du relais atteint 80 % ou 100 %, et envoyer un e-mail en cas de modification de la formule. Les recommandations de sécurité et les notifications d’état opérationnel ne sont délibérément soumises à aucune de ces restrictions.

Corrections apportées au Hardening Mode et au délai de réinitialisation des relais

Hardening Mode ne se réactive plus automatiquement pendant la période de référence de 2 heures.

Après une expiration naturelle ou une désactivation par l’administrateur, le Hardening Mode pourrait se réactiver si le même intervalle d’une minute se trouvait toujours dans la fenêtre de rétrospection SQL de 2 heures. Le marqueur partime_window marqueur stocke désormais la Payload canonique correspondant à la raison la plus forte au lieu d’un indicateur de présence, ce qui permet à la suppression de survivre à l’effacement différé des TRANSIENT_REASON et is_active() et de l’effacement explicite dans deactivate(). Une deactivate('admin') surdéfinition efface désormais également le marqueur pour la fenêtre de la raison active, de sorte que la surdéfinition soit effective.

Un bug lié à l’extension « TTL-low » a également été corrigé : TRANSIENT_REASON il expirait alors que les extensions horaires continuaient à augmenter sa valeur TRANSIENT_UNTIL, et le balayage faible suivant écrasait alors le déclencheur le plus fort d’origine. La branche d’extension actualise désormais le TTL du marqueur en même temps TRANSIENT_UNTIL et enregistre un marqueur pour la fenêtre du candidat, de sorte qu’un balayage ultérieur ne puisse pas générer un deuxième hardening_mode_extended journal pour le même compartiment.

Les événements d’attaque coordonnée se déclenchent une fois par motif, et non une fois par cycle cron.

Security_Monitor::check_coordinated_attacks() enregistre désormais un marqueur de journal de 2 heures par time_window, de sorte que l’événement structuré coordinated_attack_detected se déclenche une fois par motif au lieu d’une fois par cycle cron. cron_sync_reputation() n’enregistre plus d’agrégat en double Coordinated attacks detected agrégat en plus de cela — le bruit horaire du journal d’activité que le Changelog précédent attribuait au wrapper cron provenait en réalité de ce flux interne.

Le délai d’attente du relais 429 s’applique désormais à l’ensemble du réseau et respecte le paramètre « Retry-After »

Le délai de réessai des codes d’erreur 429 pour Mail Relay et SMS Relay est passé à set_site_transient (à l’échelle du réseau sur les environnements Multisite), préserve le code d’état HTTP d’origine dans la Payload de délai d’attente, analyse correctement les en-têtes HTTP-Date Retry-After correctement, et limite le délai de refroidissement à DAY_IN_SECONDS au lieu d’une heure. Chacune de ces modifications corrige un comportement réel observé en production : les transitoires par blog permettaient à trois sous-sites de saturer indépendamment la limite par serveur et par destinataire ; un 429 synthétique masquait un 402 de limite mensuelle sous la forme d’un message « trop d’envois » et dissimulait l’invite de mise à niveau ; une conversion de la date HTTP Retry-After convertie en (int) s’effondrait à 0 et revenait à la valeur par défaut de 5 minutes ; enfin, la limitation à une heure générait des requêtes toutes les heures alors que la limite du serveur était de 24 heures.

Petites corrections de précision

  • Le code SMS de l’authentification à deux facteurs (2FA) est désormais enregistré une fois que l’opérateur a validé l’envoi. Une écriture effectuée avant l’envoi laissait des hachages de code obsolètes dans _transient_rip_2fa_sms_code_ pendant dix minutes lorsque le relais était court-circuité en raison du délai de réessai du client.
  • Les niveaux « Enterprise » et « Honeypot » ne provoquent plus de no_quota ne sont plus court-circuités lorsque les tampons en amont remaining_reports = 0 sur un compte Unlimited. Un quota_is_unlimited() assistant gère désormais les deux has_report_quota() et get_quota_status().
  • L’action d’administration « Envoyer un e-mail de test » affiche une bannière lorsque le relais a basculé vers wp_mail(), en utilisant une nouvelle ReportedIP_Hive_API::is_relay_in_backoff() sonde, afin que vous puissiez vérifier si vous avez bien validé le chemin du relais géré.
  • La désinstallation d’un plugin efface désormais les données temporaires associées. delete_all_plugin_options Seule la correspondance option_name LIKE 'reportedip_hive_%', ce qui faisait qu’on ignorait le _transient_… et _site_transient_… ; sans cela, ces clés auraient subsisté après la désinstallation et auraient pu perturber une nouvelle installation.
  • Le menu déroulant de l’interface utilisateur « Logs » affiche désormais hardening_mode_extended et les coordinated_attack_detected comme filtres.

Comment passer à la version 2.0.16

  • 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.16 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.15 ainsi que le Changelog de l’API et des plugins. Les instructions d’installation et de configuration sont disponibles dans la documentation du plugin WordPress.

Obtenir ReportedIP Hive →

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous devez remplir ce champ
Vous devez remplir ce champ
Veuillez saisir une adresse e-mail valide.
Vous devez accepter les conditions pour continuer