Communiqués

ReportedIP 2.0.16 — Limite de fréquence des promotions et e-mails d'alerte de quota

27 mai 2026 · Patrick Schlesinger

ReportedIP 2.0.16 regroupe toutes les notifications de mise à jour sous un seul seuil de fréquence, 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 mode de renforcement de la sécurité et au délai de relâchement 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 Tableau de bord → Mises à jour ou téléchargez la version taguée sur GitHub.

Comment la limite promotionnelle unifiée modifie Hive 2.0.16 pour les administrateurs de la version gratuite

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. Toutes les surfaces promotionnelles passent par ce système : la bannière 2FA de WooCommerce, la carte de vente incitative intégrée Frontend-2FA, la carte du tableau de bord Mail/SMS-Relay et le bloc d'informations sur le mode de renforcement de la sécurité. Avant la version 2.0.16, chacune de ces surfaces disposait de son propre délai d'attente ad hoc, et ces délais pouvaient s'accumuler.

Le responsable applique quatre règles à la fois :

• Limite mondiale de 90 jours par administrateur, toutes plateformes promotionnelles confondues.
• Délai d'attente de 60 jours après un licenciement, applicable par fonctionnalité.
• Désactivation définitive par utilisateur, avec un lien « Ne plus afficher ce message ».
• Commutateur d'arrêt dans Réglages → Notifications qui masque d'un seul coup toutes les suggestions de mise à jour.

En résumé : un administrateur de la version gratuite ne voit au maximum qu'environ quatre messages promotionnels distincts par an. Cette mise à jour a également supprimé une fiche de vente business en double concernant la double authentification (2FA) en interface utilisateur, qui n'avait pas business dans l'onglet « Mode renforcé », et a augmenté le Two_Factor_Recommend Le délai de réinitialisation de la bannière contextuelle passe de 30 minutes à 14 jours. Le parcours d'intégration avec blocage définitif pour les rôles privilégiés reste inchangé : les recommandations de sécurité priment toujours sur la commodité.

Vous recevez désormais les alertes relatives aux quotas par e-mail

Une nouvelle ReportedIP_Hive_Quota_Notifier évalue l'instantané des quotas de relais après chaque actualisation cron toutes les six heures. Lorsqu'un canal dépasse 80 % ou 100 % de son quota mensuel, un e-mail d'information est envoyé à la liste des destinataires d'alerte. Chaque canal et chaque niveau dispose d'un délai de réinitialisation de 30 jours, et ce délai est réinitialisé automatiquement à chaque nouvelle période de facturation (le period_start (en changeant de mois), ce qui fait que les avertissements repartent à zéro au début du mois.

Il existe également une application intégrée au tableau de bord. Lorsque le relais de messagerie ou de SMS renvoie un code HTTP 402 (limite mensuelle) ou 429 (délai d'attente du destinataire/site), le fournisseur appose une marque à l'échelle du réseau reportedip_hive_relay_cap_state_* site-transient. Les pages d'administration affichent alors un message d'avertissement non promotionnel — qui peut être masqué pendant 24 heures — expliquant que les e-mails sont actuellement redirigés vers wp_mail() et la vérification par SMS (2FA) est suspendue, avec un lien vers les détails du quota. La prochaine tentative réussie /relay-quota Une actualisation indiquant que l'utilisation est inférieure à la limite efface automatiquement l'état.

En cas de modification du plan, envoyez un bref e-mail factuel

Tier_Upgrade::on_tier_changed gère désormais aussi bien les rétrogradations que les mises à jour. Lors d'une rétrogradation, il efface l'état obsolète de la bannière post-mise-à-jour, désactive temporairement le bouton de bascule « WooCommerce Frontend-2FA » — vos données sont conservées afin de permettre une nouvelle mise à jour ultérieure 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 de bascule situé sous Paramètres → Notifications.

Dans la version 2.0.16, cet onglet « Paramètres » comporte désormais trois options : masquer toutes les suggestions de mise à jour (désactivée par défaut — les suggestions restent affichées), envoyer un e-mail lorsque le quota du relais atteint 80 % ou 100 %, et envoyer un e-mail en cas de modification du forfait. 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 mode de durcissement et au délai de réinitialisation des relais

Le mode de durcissement ne se réactive plus pendant la période de rétrospective de deux heures

Après une expiration naturelle ou une désactivation par l'administrateur, le mode de renforcement de la sécurité pourrait se réactiver si le même intervalle de temps (minute-bucket) se trouvait toujours dans la fenêtre de rétrospective SQL de 2 heures. Le par-time_window Le marqueur stocke désormais la charge utile canonique de la raison la plus forte au lieu d'un indicateur de présence, de sorte que la suppression résiste à l'effacement différé de TRANSIENT_REASON dans is_active() et la suppression explicite dans deactivate(). Un deactivate('admin') La fonction « override » efface désormais également le marqueur de la fenêtre « live reason », ce qui permet à la modification de prendre effet.

Un bug lié à l'extension TTL-low a également été corrigé : TRANSIENT_REASON expirait alors que les prolongations horaires ne cessaient de s'enchaîner TRANSIENT_UNTIL, puis le balayage hebdomadaire suivant a supplanté le déclencheur initial, qui était le plus puissant. La branche d'extension actualise désormais la durée de vie (TTL) du marqueur parallèlement à TRANSIENT_UNTIL et enregistre un marqueur pour la fenêtre du candidat, de sorte qu'un balayage ultérieur ne puisse pas déclencher 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 cycle, et non une fois par tick du cron

Security_Monitor::check_coordinated_attacks() enregistre désormais un marqueur de journal toutes les time_window, donc la structure coordinated_attack_detected Les événements critiques se déclenchent une fois par modèle plutôt qu'une fois par cycle de cron. cron_sync_reputation() n'enregistre plus de doublons Coordinated attacks detected Et pour couronner le tout, le bruit dans le journal d'activité horaire, que le journal des modifications 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 d'attente des services relay-mail et relay-sms 429 a été modifié pour set_site_transient (à l'échelle du réseau sur les environnements multisites), conserve le code d'état HTTP d'origine dans la charge utile de délai d'attente, analyse la date HTTP Retry-After entraîne les en-têtes correctement et limite le temps de recharge à DAY_IN_SECONDS au lieu d'une heure. Chacune de ces modifications corrige un comportement réel observé en production : les variables temporaires par blog permettaient à trois sous-sites d'atteindre indépendamment la limite du serveur par destinataire ; un code d'erreur 429 synthétique masquait une limite mensuelle 402 sous la forme d'un message « trop d'envois » et dissimulait l'invite de mise à niveau ; une date HTTP Retry-After convertir en (int) est tombé à 0 et est revenu à la valeur par défaut de 5 minutes ; et la limite d'une heure a généré des requêtes toutes les heures, dans le cadre d'une limite de 24 heures imposée au serveur.

Petites corrections de bugs

• Le code SMS de l'authentification à deux facteurs est désormais enregistré après le fournisseur accepte l'envoi. Une écriture effectuée avant l'envoi a laissé des hachages de code obsolètes dans _transient_rip_2fa_sms_code_<user> pendant dix minutes, lorsque le relais a court-circuité via le mécanisme de recul du client.
• Les niveaux « Enterprise » et « Honeypot » ne sont plus mis en file d'attente no_quota provoquer un court-circuit lorsque les timbres en amont remaining_reports = 0 sur un forfait illimité. Un forfait partagé quota_is_unlimited() helper 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 bascule vers wp_mail(), en utilisant un nouveau ReportedIP_Hive_API::is_relay_in_backoff() vérifiez afin de savoir si vous avez bien validé le chemin de relais géré.
• La désinstallation d'un plugin efface désormais les données temporaires associées. delete_all_plugin_options uniquement en correspondance option_name LIKE 'reportedip_hive_%', qui a ignoré le _transient_… et _site_transient_… lignes ; sans cela, ces clés subsisteraient après la désinstallation et pourraient perturber une nouvelle installation.
• Le menu déroulant de l'interface utilisateur des journaux affiche désormais hardening_mode_extended et le structuré coordinated_attack_detected les types d'événements comme filtres.

Comment passer à la version 2.0.16

• 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.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 journal des modifications de l'API et des plugins. Les instructions d'installation et de configuration sont disponibles dans la documentation du plugin WordPress.

Obtenir ReportedIP →