ReportedIP Hive 2.0.16 – E-Mails mit Warnmeldungen zu Frequenzbegrenzungen und Kontingenten für Werbe-E-Mails
ReportedIP Hive 2.0.16 fasst alle Upgrade-Hinweise unter einer einzigen Frequenzbegrenzung zusammen, fügt Warn-E-Mails zur Relais-Kontingentauslastung bei 80 % und 100 % hinzu und behebt eine Reihe von Fehlern im Zusammenhang mit der Reaktivierung des Hardening Mode sowie der Relais-Rückhaltung. Die Version ist stabil und wird über die integrierte 12-Stunden-Update-Prüfung bereitgestellt.
Websites mit automatischer Aktualisierung erhalten das Update innerhalb von zwölf Stunden. Um es bereits jetzt zu beziehen, führen Sie bitte über „Dashboard → Updates“ eine manuelle Überprüfung durch oder laden Sie die mit einem Tag versehene Version von GitHub herunter.
Wie sich die einheitliche Werbegrenze auf Hive 2.0.16 für Administratoren der Free tier-Stufe auswirkt
Eine neue Klasse, ReportedIP_Hive_Promo_Manager, ist nun die einzige zuverlässige Quelle für die Frage „Darf dieser Upgrade-Hinweis jetzt angezeigt werden?“. Jede Werbefläche wird über diese Klasse geleitet: das WooCommerce-2FA-Banner, die Frontend 2FA-Inline-Upsell-Karte, die Mail-/SMS Relay-Dashboard-Karte und der Infoblock zum Hardening Mode. Vor Version 2.0.16 hatte jede dieser Komponenten ihre eigene Ad-hoc-Wartezeit, und diese konnten sich summieren.
Der Manager setzt vier Regeln gleichzeitig durch:
- Weltweite Obergrenze von 90 Tagen pro Administrator über alle Werbeplattformen hinweg.
- 60-tägige Wartezeit nach einer Entlassung, je nach Funktion unterschiedlich.
- Dauerhafte Abmeldung pro Benutzer mit einem Link „Dies nicht erneut anzeigen“.
- Ein Schalter unter „Einstellungen“ → „Benachrichtigungen“, mit dem Sie alle Update-Hinweise auf einmal ausblenden können.
Das Ergebnis: Ein Administrator der Free tier-Stufe sieht höchstens etwa vier separate Werbemaßnahmen pro Jahr. Mit diesem Release wurde zudem eine doppelte Upsell-Karte für „Frontend 2FA“ entfernt, die auf der Registerkarte „Hardening Mode“ nichts zu suchen hatte, und die Two_Factor_Recommend Wartezeit für das Schließen des Soft-Banners von 30 Minuten auf 14 Tage erhöht. Der Onboarding-Pfad mit harter Sperre für privilegierte Rollen bleibt unverändert – eine Sicherheitsempfehlung hat weiterhin Vorrang vor dem Komfort.
Benachrichtigungen zu Quotenüberschreitungen erhalten Sie nun per E-Mail
Eine neue ReportedIP_Hive_Quota_Notifier wertet nach jeder sechsstündigen Cron-Aktualisierung den Snapshot der Relay-Kontingente aus. Wenn ein Kanal 80 % oder 100 % seines monatlichen Kontingents überschreitet, versendet er eine Informations-E-Mail an die Liste der Alarmempfänger. Jeder Kanal und jede Stufe verfügt über eine 30-tägige Abkühlphase, die sich zu Beginn jedes neuen Abrechnungszeitraums (dem period_start Wechsel), sodass die Warnungen zu Beginn eines neuen Monats von Neuem beginnen.
Zudem gibt es eine entsprechende Funktion im Dashboard. Wenn die Mail Relay oder SMS Relay den HTTP-Status 402 (monatliches Limit) oder 429 (Empfänger-/Website-Backoff) zurückgibt, setzt der Anbieter ein netzwerkweites reportedip_hive_relay_cap_state_* „site-transient“-Markierung. Auf den Administrationsseiten wird daraufhin ein nicht werblicher Warnhinweis angezeigt – der 24 Stunden lang geschlossen werden kann –, in dem erläutert wird, dass E-Mails derzeit auf wp_mail() und die SMS-2FA pausiert ist, mit einem Link zu den Kontingentdetails. Die nächste erfolgreiche /relay-quota Aktualisierung, bei der die Nutzung unterhalb des Limits liegt, hebt diesen Status automatisch auf.
Bei Planänderungen senden Sie bitte eine kurze, sachliche E-Mail
Tier_Upgrade::on_tier_changed verarbeitet nun sowohl Downgrades als auch Upgrades. Bei einem Downgrade wird der veraltete Status des Banners nach dem Upgrade zurückgesetzt, die Umschaltfunktion für „WooCommerce Frontend 2FA“ wird vorübergehend deaktiviert – Ihre Daten bleiben dabei erhalten, sodass ein späteres erneutes Upgrade nahtlos erfolgt – und es wird eine kurze, sachliche E-Mail versendet. Upgrades lösen eine entsprechende Willkommens-E-Mail aus, die auf die verbleibenden Einrichtungsschritte hinweist. Beide E-Mails können über den neuen Schalter unter „Einstellungen“ → „Benachrichtigungen“ unterdrückt werden.
In Version 2.0.16 wird die Registerkarte „Einstellungen“ um drei Schaltflächen erweitert: „Alle Upgrade-Hinweise ausblenden“ (standardmäßig deaktiviert – die Hinweise bleiben weiterhin angezeigt), „E-Mail senden, wenn das Relay-Kontingent 80 % oder 100 % erreicht“ und „E-Mail senden, wenn sich der Tarif ändert“. Sicherheitsempfehlungen und Benachrichtigungen zum Betriebsstatus unterliegen bewusst keiner dieser Einschränkungen.
Korrekturen im „Hardening Mode“ und beim Relais-Backoff
The Hardening Mode is not automatically reactivated within the 2-hour lookback period.
Nach einem natürlichen Ablauf oder einer Deaktivierung durch den Administrator könnte sich der Hardening Mode erneut aktivieren, wenn sich derselbe Minuten-Bucket noch innerhalb des 2-stündigen SQL-Rückblickzeitraums befindet. Der Marker protime_window Marker speichert nun die kanonische „Strongest-Reason“-Payload anstelle eines Präsenz-Flags, sodass die Unterdrückung das verzögerte Löschen von TRANSIENT_REASON sowie is_active() sowie der expliziten Löschung in deactivate(). Ein deactivate('admin') Überschreibung löscht nun auch den Marker für das Zeitfenster des aktuellen Grundes, sodass die Überschreibung bestehen bleibt.
Ein damit zusammenhängender Fehler bei der TTL-Low-Erweiterung wurde ebenfalls behoben: TRANSIENT_REASON Dieser lief früher ab, während stündliche Verlängerungen den Wert immer wieder erhöhten TRANSIENT_UNTIL, woraufhin der nächste schwache Durchlauf den ursprünglich stärksten Auslöser überschrieb. Der Verlängerungszweig aktualisiert nun die TTL-Markierung gleichzeitig TRANSIENT_UNTIL und zeichnet einen Marker für das Fenster des Kandidaten auf, sodass ein nachfolgender Durchlauf keinen zweiten hardening_mode_extended Protokoll für denselben Bucket auslösen.
Ereignisse mit koordinierten Angriffen werden einmal pro Muster ausgelöst, nicht einmal pro Cron-Tick.
Security_Monitor::check_coordinated_attacks() schreibt nun pro time_window, sodass der strukturierte coordinated_attack_detected kritische Ereignis wird nun einmal pro Muster ausgelöst, anstatt einmal pro Cron-Durchlauf. cron_sync_reputation() Es wird kein doppeltes Coordinated attacks detected Aggregat – das stündliche Rauschen im Aktivitätsprotokoll, das in einem früheren Changelog dem Cron-Wrapper zugeschrieben wurde, stammte tatsächlich von diesem internen Stream.
Die Backoff-Funktion von Relay 429 gilt nun netzwerkweit und berücksichtigt die „Retry-After“-Einstellung
Die Backoff-Zeiten für „relay-mail“ und „relay-sms“ 429 wurden auf set_site_transient (netzwerkweit bei Multisite), bewahrt den ursprünglichen HTTP-Statuscode in der Cooldown-Payload bei, wertet die HTTP-Datei-Header Retry-After korrekt und begrenzt die Abkühlphase auf DAY_IN_SECONDS statt auf eine Stunde. Jede dieser Maßnahmen behebt ein tatsächlich in der Produktion beobachtetes Verhalten: Transienten pro Blog führten dazu, dass drei Unterseiten unabhängig voneinander die Server-Obergrenze pro Empfänger überschritten; ein synthetischer 429-Fehler maskierte eine 402-Monatsobergrenze als „Zu viele Sendungen“-Meldung und verbarg die Aufforderung zum Upgrade; ein HTTP-Date- Retry-After wurde auf (int) brach auf 0 zusammen und fiel auf einen Standardwert von 5 Minuten zurück; und die Begrenzung auf eine Stunde führte zu stündlichen Abfragen bei einer 24-Stunden-Server-Obergrenze.
Kleinere Korrekturen zur Fehlerbehebung
- Der temporäre 2FA-SMS-Code wird nun erst geschrieben, nachdem der Anbieter den Versand akzeptiert hat. Durch einen Schreibvorgang vor dem Versand blieben veraltete Code-Hashes
_transient_rip_2fa_sms_code_, wenn das Relay aufgrund der Backoff-Zeit des Clients kurzgeschlossen wurde. - Die Stufen „Enterprise“ und „Honeypot“ gelangen nicht mehr in die Warteschlange
no_quotaeinen Kurzschluss, wenn der Upstream-Stempelremaining_reports = 0bei einem Unlimited-Konto. Ein gemeinsamerquota_is_unlimited()Helper steuert nun beidehas_report_quota()undget_quota_status(). - Die Administratoraktion „Test-E-Mail senden“ zeigt ein Banner an, wenn der Mail Relay auf
wp_mail(), wobei ein neuerReportedIP_Hive_API::is_relay_in_backoff()Test, damit Sie erkennen können, ob Sie den Managed-Relay-Pfad tatsächlich validiert haben. - Beim Deinstallieren eines Plugins werden nun die temporären Daten des Plugins gelöscht.
delete_all_plugin_optionsEs wurde nuroption_name LIKE 'reportedip_hive_%', wodurch die_transient_…und_site_transient_…Zeilen übersprungen wurden; diese Schlüssel würden andernfalls die Deinstallation überstehen und bei einer Neuinstallation zu Verwirrung führen. - Das Dropdown-Menü der Protokoll-Benutzeroberfläche listet nun
hardening_mode_extendedsowie die strukturiertencoordinated_attack_detectedEreignistypen als Filter auf.
So führen Sie ein Update auf Version 2.0.16 durch
- Automatische Aktualisierung innerhalb des Plugins. Der „Plugin Update Checker“ fragt alle 12 Stunden die GitHub Releases ab. Wenn Sie nicht warten möchten, können Sie eine Überprüfung über „Dashboard“ → „Updates“ erzwingen.
- Manueller Download. Laden Sie die ZIP-Datei aus der Version v2.0.16 auf GitHub herunter.
- WP-CLI.
wp plugin update reportedip-hivefalls Sie WordPress über die Befehlszeile verwalten.
Informationen zur vorherigen Version sowie die vollständige Versionshistorie finden Sie in den Versionshinweisen zu 2.0.15 sowie im Changelog für die API und die Plugins. Informationen zur Installation und Konfiguration finden Sie in der Dokumentation zum WordPress-Plugin.