Ablauf

Ruft ein Besucher die Login-Seite auf, erscheint zunächst nur die Gate-Seite mit einem einzelnen Button „Jetzt einloggen“. Ein Klick darauf setzt (optional nach erfolgreicher reCAPTCHA-Prüfung im Hintergrund) einen kurzlebigen Cookie und leitet zurück zur Login-Seite – erst jetzt erscheint das eigentliche Formular für Benutzername und Passwort.

Netzwerkweit, zentral gesteuert

Anders als die meisten Module lässt sich das Login Gate nicht pro Site ein- oder ausschalten – es gibt eine einzige, zentrale Einstellung unter Weinhold Netzwerk → Login Gate, die für alle Sites gleichzeitig gilt. Zusätzlich lässt sich einstellen, wie lange der Gate-Cookie nach dem Klick gültig bleibt (1–60 Minuten).

Zusammenspiel mit reCAPTCHA

Ist das reCAPTCHA-Modul aktiv, wird beim Klick auf den Gate-Button zusätzlich ein unsichtbarer reCAPTCHA-Score geprüft, bevor der Cookie gesetzt wird. Ohne aktives reCAPTCHA-Modul funktioniert das Gate trotzdem – dann zählt allein der Button-Klick.

modules/login_gate_core.php – einzige Datei des Moduls (Core-Modul, das _core.php-Suffix lädt es immer): Cookie-/Token-Verwaltung, POST-Handler für den Gate-Klick, Gate-Seiten-Rendering, Admin-Einstellungen, Cleanup.

Einhängepunkt: weinhold_auth_login_override

Login Gate hängt sich mit Priorität 5 in denselben Filter weinhold_auth_login_override ein, über den auch das Gerätesicherheit-Modul seine Challenge-Seite anzeigt. Ist das Gate aktiv und kein gültiger Cookie vorhanden, liefert es HTML für die Vorraum-Seite statt null zurück – das Benutzerverwaltung-Modul zeigt dieses HTML dann anstelle des normalen Login-Formulars.

Cookie & Transient

Nach dem Button-Klick wird ein zufälliger Token erzeugt, als Transient wf_gate_{token} mit der konfigurierten Lebensdauer gespeichert und zusätzlich als HttpOnly-Cookie wf_login_gate (SameSite=Strict, Secure bei SSL) im Browser abgelegt. weinhold_login_gate_has_valid_cookie() prüft bei jedem Login-Seitenaufruf, ob Cookie-Wert und Transient noch zusammenpassen.

Schutz vor direkten POST-Angriffen

Das Security-Manager-Modul liest denselben Cookie-Namen (wf_login_gate) und denselben Transient-Präfix in seiner eigenen Funktion weinhold_security_block_gateless_post() – ein POST direkt auf die Login-Verarbeitung ohne gültigen Gate-Cookie wird dort blockiert, unabhängig vom Gate-Rendering selbst. Die beiden Module sind also bewusst über den Cookie-Namen gekoppelt, nicht über einen direkten Funktionsaufruf.

Keine Per-Site-Steuerung: Bewusste Design-Entscheidung, weil ein Bot-Schutz nur netzwerkweit konsistent wirksam ist – eine einzelne ungeschützte Subsite würde sonst weiterhin direkte Angriffe erlauben.

reCAPTCHA-Prüfung passiert zweimal im vollen Flow: einmal beim Gate-Klick (dieses Modul) und ein zweites Mal beim eigentlichen Login-Submit (Benutzerverwaltung-Modul, sofern dort ebenfalls aktiviert) – zwei unabhängige Kontrollpunkte statt einem.

Fehlermeldungen (ungültiger Nonce, fehlgeschlagene reCAPTCHA-Prüfung) werden IP-basiert als kurzlebiger Transient zwischengespeichert und beim nächsten Aufruf der Gate-Seite einmalig angezeigt – kein Session- oder Cookie-basierter Mechanismus dafür nötig.