ReportedIP 2.0.22 – Sensor zum Ausblenden der Anmeldung, deutsche Benutzeroberfläche und optimierte 2FA-Anmeldung
ReportedIP 2.0.22 ist der Höhepunkt von fünf Releases, die seit Version 2.0.16 veröffentlicht wurden: ein neuer „Hide-Login“-Probe-Sensor, eine vollständige deutsche Benutzeroberfläche und ein 2FA-Anmeldeablauf, der keine unerwünschten Codes mehr versendet. All diese Neuerungen werden über die integrierte 12-Stunden-Update-Prüfung auf bestehende Websites übertragen.
Dieser Überblick umfasst alle Versionen zwischen 2.0.17 und 2.0.22. Websites mit automatischer Aktualisierung erhalten die neueste Version innerhalb von zwölf Stunden; über „Dashboard → Updates“ können Sie die Überprüfung manuell auslösen, um sie sofort herunterzuladen.
Was ist neu in ReportedIP 2.0.22 und den vorherigen Versionen?
Die Arbeit gliedert sich in vier Bereiche: einen neuen Sensor für die Anmeldeüberprüfung, einen optimierten und stabileren 2FA-Ablauf, eine vollständige deutsche Übersetzung sowie eine Reihe von Korrekturen im Bereich E-Mail und Stabilität. Jede der unten aufgeführten Versionen ist eine echte, auf GitHub getaggte Veröffentlichung.
- 2.0.17 – Sperren aufgrund der erzwungenen 2FA werden nicht mehr fälschlicherweise als „Ungültige Anmeldedaten“ angezeigt.
- 2.0.19 – Deutsche Übersetzung, eine Korrektur für einen schwerwiegenden PHP-8-Fehler auf der Registerkarte „2FA-Einstellungen“ und ein CI-Gate zur Überprüfung der Aktualität der Übersetzungen.
- 2.0.20 – keine wiederholten E-Mails mit dem Hinweis „Plan ist aktiv“ mehr, eine optimierte 2FA-Einrichtung und kein unerwünschtes Versenden von E-Mail-/SMS-Codes mehr.
- 2.0.21 – Der „Hide-Login“-Probesensor und eine Methodenauswahl, die auf schmalen Anmeldekarten nicht mehr abgeschnitten wird.
- 2.0.22 – Die 2FA-Abfrage behält nach einem fehlgeschlagenen Code die von Ihnen gewählte Methode bei, anstatt auf die vorherige zurückzusetzen.
Der „Hide-Login“-Sensor blockiert Scans Ihrer alten Anmelde-URL
Wenn Sie die Funktion „Hide Login“ von Hive nutzen, befindet sich Ihre eigentliche Anmeldeseite unter einem benutzerdefinierten Slug und /wp-login.php sollte von einem legitimen Besucher niemals aufgerufen werden. In Version 2.0.21 wird dies zu einem Erkennungssignal: Wiederholte direkte Zugriffe auf die alte /wp-login.php Zugriffe von einer IP-Adresse werden nun als Scan behandelt, nach derselben Eskalationsstufe wie die anderen Sensoren blockiert und der Community gemeldet.
Ein einzelner zufälliger Zugriff bleibt harmlos – es wird lediglich ein Recon-Protokoll mit geringer Schweregradstufe erstellt. Erst ein wiederkehrendes Muster löst die Sperre aus. Der Sensor lässt sich auf der Registerkarte „Anmeldeeinstellungen“ konfigurieren: über einen Hauptschalter (standardmäßig aktiviert), einen Schwellenwert für Treffer (standardmäßig 5) und einen Zeitrahmen (standardmäßig 10 Minuten). IP-Adressen auf der Whitelist werden nie gezählt, sodass Ihre eigene Überwachung den Sensor niemals auslöst.
Dies ergänzt die in den Versionshinweisen zu 2.0.16 beschriebene Erkennung von Köder-Pfaden: Köder-Pfade erkennen Angriffe auf Anmeldedaten und Sicherungsdateien, während der „Hide-Login“-Sensor Brute-Force-Tools abfängt, die weiterhin die Standard-Anmelde-URL bombardieren.
Der 2FA-Anmeldeprozess sendet keine Codes mehr, die Sie nie angefordert haben
Vor Version 2.0.20 erhielt ein Benutzer, dessen bevorzugte Methode E-Mail oder SMS war, einen Einmalcode, sobald der Bestätigungsbildschirm geladen wurde – noch bevor er überhaupt eine Methode auswählen konnte. Bei beiden Zustellmethoden beginnt nun die Anforderungsphase: Man wählt die Methode aus und klickt auf „Code senden“, bevor etwas versendet wird. Stateless-Methoden (Authentifizierungs-App, Passkey, Wiederherstellungscodes) sind davon nicht betroffen und zeigen die Eingabe direkt an.
Die praktische Auswirkung: keine unerwünschten E-Mails oder SMS und keine Überschreitung des Ratenlimits oder des verwalteten Relay-Kontingents für eine Methode, die der Benutzer nicht ausgewählt hat. Bei einer stark frequentierten Shop-Anmeldung spielt dieses Kontingent eine wichtige Rolle – lesen Sie in den Versionshinweisen zu 2.0.16 nach, wie Relay-Kontingente und die Warn-E-Mails bei 80 % bzw. 100 % funktionieren.
Die Herausforderung besteht nun darin, dass Ihre Methode nach einem fehlerhaften Code weiterläuft
Version 2.0.22 behebt eine ärgerliche Schleife. Wenn mehrere Methoden konfiguriert waren, sprang die Seite beim Wechsel vom Reiter „E-Mail“ zum Reiter „SMS“, bei der Anforderung eines Codes und der Eingabe eines falschen oder abgelaufenen Codes sofort zurück zum Reiter „E-Mail“ – wobei sowohl die gewählte Methode als auch der eingegebene Code verloren gingen. Der Challenge-Handler behält nun die übermittelte Methode auch bei einer Neuanzeige (fehlgeschlagene Verifizierung, Soft-Lockout) bei, sodass Sie auf Ihrem Reiter bleiben, den Fehler sehen und den Code erneut eingeben können. Der Wert wird weiterhin anhand der aktiven Methoden des Kontos validiert, sodass eine gefälschte Methode sicher zurückgewiesen wird. Sowohl die wp-login.php und der WooCommerce-Frontend-Ablauf werden behandelt.
Die Methodenauswahl wird nicht mehr auf „A…/E…/S…/W…“ gekürzt
Innerhalb einer schmalen, themenbezogenen Anmeldespalte wurden die Registerkarten für die Anmeldemethoden bisher auf einbuchstabige Abkürzungen reduziert. Der Selektor passt sich nun über eine CSS-Container-Abfrage an die tatsächliche Kartenbreite an und stapelt die Methoden bei Platzmangel als vertikale Liste mit vollständigen Bezeichnungen, sodass „Authenticator“, „E-Mail“, „SMS“ und „WebAuthn“ gut lesbar bleiben.
Hive 2.0.19 bietet eine vollständige deutsche Benutzeroberfläche
Alle benutzersichtbaren Zeichenfolgen – insgesamt etwa 1.845 – sind nun ins Deutsche (de_DE, formelle Anrede „Sie“) übersetzt und werden als kompilierte .po / .mo Paar. Die Quelltexte bleiben auf Englisch; WordPress lädt die deutsche Übersetzung automatisch, wenn die Sprache der Website auf Deutsch eingestellt ist, sodass alle anderen Sprachversionen davon unberührt bleiben.
Um diese Übersetzung authentisch zu halten, wurde in derselben Version ein „Freshness Gate“ eingeführt. composer i18n:check Der Build schlägt fehl, wenn die Übersetzungsvorlage veraltet ist, die deutsche Datei unübersetzte oder unklare Einträge enthält oder die kompilierte Binärdatei nicht mehr synchron ist. Der Vorgang läuft als blockierender CI-Job, sodass die deutsche Benutzeroberfläche bei jeder Änderung mit dem Quellcode synchronisiert wird. Mit diesem Release wurde außerdem der „tested-up-to“-Header auf WordPress 7.0 aktualisiert.
Behebung von Problemen mit dem Lockout, E-Mails und der Stabilität
Bei 2FA-Sperren wird nicht mehr „Ungültige Anmeldedaten“ angezeigt
In Version 2.0.17 wurde einem Benutzer, der das Kontingent für das Überspringen der 2FA-Einrichtung ausgeschöpft hatte, der eigentliche Grund – „Zwei-Faktor-Authentifizierung erforderlich – Kontingent für Überspringen ausgeschöpft, wenden Sie sich an einen Administrator“ – durch die Anmeldemaske zur Benutzerauflistung in die allgemeine Meldung „Ungültige Anmeldedaten“ umgeschrieben. Dies führte dazu, dass ausgesperrte Administratoren eine unnötige Passwortzurücksetzung durchführten. Die Maske lässt nun 2FA-Meldungen durch, da dieser Block erst nach der Passwortvalidierung ausgelöst wird; somit verrät die Anzeige des Grundes nichts darüber, ob der Benutzername existiert. Echte Anmeldefehler bleiben verborgen.
Keine wiederholten E-Mails mehr mit dem Hinweis „Plan ist aktiv“
Die Willkommens-E-Mail bei einem Tier-Wechsel leitete das vorherige Tier früher aus einem fünfminütigen Status-Transient ab. Sobald dieser Transient abgelaufen war, wurde das vorherige Tier auf „Free“ zurückgesetzt, sodass jede nachfolgende Aktualisierung eines kostenpflichtigen Schlüssels einen fiktiven Übergang von „Free“ zu „Paid“ erkannte und die E-Mail erneut versendete. In Version 2.0.20 wird die Basislinie in eine dauerhafte Option umgewandelt: Die erste Beobachtung setzt sie stillschweigend und die E-Mail wird nur bei einem echten Tier-Wechsel ausgelöst. Live verifiziert als null Auslösungen bei wiederholten Aktualisierungen eines aktiven Tiers und genau eine Auslösung bei einem echten Upgrade.
Kleinere Korrekturen
- 2.0.19 — a
TypeErrorIn PHP 8 wurden die Registerkarte „2FA-Einstellungen“ und der Schritt im Einrichtungsassistenten entfernt, wenn die Optionen „enforce-roles“ oder „allowed-methods“ als Array gespeichert wurden. Lesevorgänge werden nun über einen formatunabhängigen Helper abgewickelt. - 2.0.20 — Der Einrichtungsassistent hat stillschweigend „enforced-2FA“-Rollen entfernt, deren Slug nicht in Kleinbuchstaben geschrieben war (Rollen des Membership-Plugins wie
um_Premium-Member); nun wird der Slug beibehalten, entsprechend den Einstellungen auf der Registerkarte. - 2.0.20 — Admin-Hinweise wurden auf Admin-Seiten ohne Plugins nicht formatiert, und die Hauptschaltfläche verlor innerhalb von WordPress ihren Kontrast
.notice. Auf jedem Admin-Bildschirm wird nun ein eigenständiges Stylesheet mitgeliefert. - 2.0.20 – Der Assistent für die 2FA-Einrichtung ist nun direkt über das Empfehlungsbanner und den 2FA-Bereich im Profil aufrufbar, und der Assistent selbst wurde gestrafft.
So führen Sie ein Update auf Version 2.0.22 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 v2.0.22 auf GitHub herunter.
- WP-CLI.
wp plugin update reportedip-hivewenn Sie WordPress über die Befehlszeile verwalten.
Informationen zur vorherigen Version und zur vollständigen Versionshistorie finden Sie in den Versionshinweisen zu 2.0.16 sowie im Änderungsprotokoll für API und Plugins. Informationen zur Einrichtung, zur Funktion „Anmeldung ausblenden“ und zur 2FA-Konfiguration finden Sie in der Dokumentation zum WordPress-Plugin.