Veröffentlichungen

ReportedIP 2.0.16 – E-Mails zu Warnmeldungen bezüglich Werbebeschränkungen und Kontingenten

Mai 27, 2026 · Patrick Schlesinger

ReportedIP 2.0.16 fasst alle Upgrade-Hinweise unter einer einzigen Frequenzbegrenzung zusammen, fügt Benachrichtigungs-E-Mails bei Erreichen von 80 % und 100 % der Relais-Quote hinzu und behebt eine Reihe von Fehlern im Zusammenhang mit der erneuten Aktivierung des Hardening-Modus und 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 sofort abzurufen, lösen Sie eine manuelle Überprüfung über „Dashboard → Updates“ aus oder laden Sie die markierte Version von GitHub herunter.

Wie sich die einheitliche Werbegrenze auf Hive 2.0.16 für Administratoren der kostenlosen Version 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?“. Alle Werbeflächen werden darüber gesteuert: das WooCommerce-2FA-Banner, die Frontend-2FA-Inline-Upsell-Karte, die Mail/SMS-Relay-Dashboard-Karte und der Info-Block zum Hardening-Modus. 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 Sperrfrist nach einer Entlassung, je nach Funktion.
• Dauerhafte Abmeldung pro Benutzer mit einem Link „Nicht mehr anzeigen“.
• Ein Schalter unter „Einstellungen“ → „Benachrichtigungen“, der alle Update-Hinweise auf einmal ausblendet.

Das Ergebnis: Ein Administrator der kostenlosen Version sieht höchstens etwa vier einzelne Werbemaßnahmen pro Jahr. Mit diesem Update wurde zudem eine doppelte Upsell-Karte für „Frontend-2FA“ entfernt, die auf der Registerkarte „Hardening Mode“ nichts business hatte, und die Two_Factor_Recommend Die Wartezeit für das Schließen des Soft-Banners wird von 30 Minuten auf 14 Tage verlängert. Der Onboarding-Prozess mit Hard-Block für privilegierte Rollen bleibt unverändert – eine Sicherheitsempfehlung hat weiterhin Vorrang vor dem Komfort.

Benachrichtigungen zu Kontingenten werden Ihnen nun per E-Mail zugestellt

Ein neues ReportedIP_Hive_Quota_Notifier wertet den Relay-Quota-Snapshot nach jeder sechsstündigen Cron-Aktualisierung aus. Wenn ein Kanal 80 % oder 100 % seines monatlichen Kontingents überschreitet, wird eine Benachrichtigungs-E-Mail an die Liste der Alarmempfänger gesendet. Jeder Kanal und jede Stufe unterliegt einer 30-tägigen Sperrfrist, die sich mit jedem neuen Abrechnungszeitraum automatisch zurücksetzt (die period_start (umblättern), sodass die Warnungen mit Beginn eines neuen Monats von vorne beginnen.

Es gibt auch eine entsprechende Funktion im Dashboard. Wenn der E-Mail- oder SMS-Relay den HTTP-Status 402 (monatliches Limit) oder 429 (Empfänger-/Website-Backoff) zurückgibt, versieht der Anbieter eine netzwerkweite reportedip_hive_relay_cap_state_* site-transient. Auf den Admin-Seiten wird dann ein nicht werblicher Warnhinweis angezeigt – der 24 Stunden lang ausgeblendet werden kann –, in dem erklärt wird, dass E-Mails derzeit auf wp_mail() und SMS-2FA ist deaktiviert, mit einem Link zu den Kontingentdetails. Die nächste erfolgreiche /relay-quota Eine Aktualisierung, die anzeigt, dass die Nutzung unter dem Limit liegt, löscht den Status automatisch.

Bei Planänderungen eine kurze, sachliche E-Mail senden

Tier_Upgrade::on_tier_changed behandelt nun sowohl Downgrades als auch Upgrades. Bei einem Downgrade wird der veraltete Status des Banners nach dem Upgrade zurückgesetzt, die WooCommerce-Frontend-2FA-Schaltfläche vorübergehend deaktiviert – Ihre Daten bleiben dabei erhalten, sodass ein späteres erneutes Upgrade nahtlos verläuft – 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.

In Version 2.0.16 werden auf dieser Registerkarte „Einstellungen“ drei neue Schaltflächen hinzugefügt: „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 sind bewusst von diesen Einstellungen ausgenommen.

Korrekturen am Härtungsmodus und am Relais-Backoff

Der „Hardening“-Modus wird innerhalb des 2-stündigen Rückblickzeitraums nicht mehr automatisch neu aktiviert

Nach einem natürlichen Ablauf oder einer Deaktivierung durch den Administrator könnte sich der Hardening-Modus erneut aktivieren, wenn sich derselbe Minuten-Bucket noch innerhalb des zweistündigen SQL-Rückblickzeitraums befindet. Der pro-time_window Der Marker speichert nun die kanonische „strongest-reason“-Nutzlast anstelle eines Präsenz-Flags, sodass die Unterdrückung das verzögerte Löschen von TRANSIENT_REASON in is_active() und das explizite Löschen in deactivate(). Ein deactivate('admin') „Override“ löscht nun auch die Markierung für das Fenster des aktuellen Grundes, sodass die Überschreibung bestehen bleibt.

Ein damit zusammenhängender Fehler bei der TTL-Low-Erweiterung wurde ebenfalls behoben: TRANSIENT_REASON früher lief sie ab, während stündliche Verlängerungen sie immer wieder verschoben TRANSIENT_UNTIL, und der nächste schwache Durchlauf hat dann den ursprünglich stärksten Trigger übertrumpft. Der Erweiterungszweig aktualisiert nun die TTL des Markers parallel dazu TRANSIENT_UNTIL und speichert einen Marker für das Fenster des Kandidaten, sodass ein nachfolgender Durchlauf keinen zweiten hardening_mode_extended Protokoll für denselben Bucket.

Ereignisse für koordinierte Angriffe werden einmal pro Muster ausgelöst, nicht einmal pro Cron-Tick

Security_Monitor::check_coordinated_attacks() schreibt nun alle 2 Stunden einen Protokollmarker time_window, also die strukturierte coordinated_attack_detected Das kritische Ereignis wird einmal pro Muster statt einmal pro Cron-Durchlauf ausgelöst. cron_sync_reputation() wird nicht mehr doppelt protokolliert Coordinated attacks detected Hinzu kommt noch Folgendes: Das stündliche Rauschen im Aktivitätsprotokoll, das in einem früheren Changelog dem Cron-Wrapper angelastet wurde, stammte in Wirklichkeit aus diesem internen Stream.

Die Backoff-Funktion von Relay 429 gilt nun netzwerkweit und berücksichtigt die Retry-After-Einstellung

Die Backoff-Funktion für „relay-mail“ und „relay-sms“ 429 wurde umgestellt auf set_site_transient (netzwerkweit bei Multisite), behält den ursprünglichen HTTP-Statuscode in der Cooldown-Nutzlast bei, analysiert das HTTP-Datum Retry-After Header korrekt und begrenzt die Abklingzeit auf DAY_IN_SECONDS anstelle von einer Stunde. Jede dieser Korrekturen behebt ein tatsächlich in der Produktion beobachtetes Verhalten: Durch blog-spezifische Transienten konnten drei Unterseiten unabhängig voneinander das Empfänger-spezifische Serverlimit überschreiten; ein synthetischer 429-Fehler maskierte ein 402-Monatslimit als „Zu viele Sendungen“-Meldung und verbarg die Aufforderung zum Upgrade; ein HTTP-Datum Retry-After umwandeln in (int) auf 0 zurückgesetzt und auf die Standarddauer von 5 Minuten zurückgesetzt; die einstündige Begrenzung erzeugte stündliche Abfragen bei einer Server-Obergrenze von 24 Stunden.

Kleinere Korrekturen

• Der temporäre 2FA-SMS-Code wird nun geschrieben danach Der Anbieter akzeptiert die Übertragung. Ein Schreibvorgang vor der Übermittlung hinterließ veraltete Code-Hashes in _transient_rip_2fa_sms_code_<user> zehn Minuten lang, als das Relais durch den Client-Backoff einen Kurzschluss verursachte.
• Die Stufen „Enterprise“ und „Honeypot“ landen nicht mehr in der Warteschlange no_quota Kurzschluss, wenn die vorgelagerten Stempel remaining_reports = 0 bei einem unbegrenzten Konto. Ein gemeinsames quota_is_unlimited() Der Helfer steuert nun beides has_report_quota() und get_quota_status().
• Die Admin-Aktion „Test-E-Mail senden“ blendet ein Banner ein, wenn der Relay-Server auf wp_mail(), unter Verwendung eines neuen ReportedIP_Hive_API::is_relay_in_backoff() Überprüfen Sie dies, damit Sie wissen, 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_options nur übereinstimmend option_name LIKE 'reportedip_hive_%', das die _transient_… und _site_transient_… Zeilen; diese Schlüssel würden andernfalls nach der Deinstallation erhalten bleiben und bei einer Neuinstallation zu Verwirrung führen.
• Das Dropdown-Menü der Protokoll-Benutzeroberfläche listet nun Folgendes auf hardening_mode_extended und die strukturierte coordinated_attack_detected Ereignistypen als Filter.

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. Lade die ZIP-Datei aus der Version 2.0.16 auf GitHub herunter.
• WP-CLI. wp plugin update reportedip-hive wenn Sie WordPress über die Befehlszeile verwalten.

Informationen zur vorherigen Version und die vollständige Versionshistorie finden Sie in den Versionshinweisen zu 2.0.15 sowie im Änderungsprotokoll für API und Plugins. Informationen zur Installation und Konfiguration finden Sie in der WordPress-Plugin-Dokumentation.

Zu ReportedIP →