Änderungsprotokoll

1.0.10 — 2026-08-12

WooCommerce-Checkout-Block-Draft-Updates werden nicht mehr mit truesift_verification_required abgewiesen, wenn WordPress eine Store-API-Anfrage PUT /checkout technisch als HTTP POST mit X-HTTP-Method-Override: PUT transportiert.
Die Store-API-Proof-Validierung folgt jetzt der REST-Method-Override-Priorität von WordPress und verbraucht einen TrueSift-Proof nur für die effektive finale Anfrage POST /wc/store[/vN]/checkout.
Die fail-closed Proof-Prüfung für den tatsächlichen Place-order-Request bleibt erhalten; fehlende, ungültige, abgelaufene, erneut verwendete, nicht passende, mit review bewertete oder blockierte Proofs werden weiterhin abgewiesen.

Die referenzierte offizielle Client-SDK-Version und das Browser-Bundle wurden auf @truesift/next@0.2.1 aktualisiert.
Explizite Metadaten für Plugin, SDK, Contract, Browser-Bundle und Asset-Revision wurden über window.TrueSiftWordPressBuild ergänzt.
Browser-Diagnosen für das geladene SDK-Global, den TrueSiftCheck-Export, die geladene SDK-Version und gemountete Admin-Vorschauen wurden hinzugefügt.
Die SDK-Cache-Revision wurde auf den kombinierten Release-Schlüssel 1.0.9-0.2.1 geändert.
Das verifizierte Proof-Consumption-Verhalten für den WordPress-Login und die Fallback-Vorschaugalerie wurden beibehalten.

Versionierte, SDK-generierte Fallback-Vorschauen für Checkbox-, Banner-, Inline- und Badge-Admin-Karten wurden hinzugefügt.
Verzögertes und idempotentes Mounting der Live-Vorschau für Optimierungs-Plugins, die JavaScript verzögert laden, wurde ergänzt.
Die Cache-Version des gebündelten SDK-Assets wurde an die WordPress-Plugin-Version gekoppelt, damit korrigierte Adapter-Bundles nicht in Optimierungs-Caches veralten.

Die serverseitige Proof-Akzeptanz für den offiziellen TrueSift-0.2-Vertrag wurde korrigiert.
Erfolgreicher einmaliger Proof-Verbrauch wird nun akzeptiert, wenn die API entweder consumed: true oder einen nicht leeren Zeitstempel consumedAt zurückgibt.
Strikte Prüfungen für allowed: true, decision: allow, Challenge-ID, Action, Path und Origin bleiben erhalten.
Sichere Debug-Diagnosen wurden um das normalisierte Ergebnis der Verbrauchsbestätigung erweitert.

Persistenter, nur für Administratoren verfügbarer TrueSift-Debug-Modus für Challenge, Verify, Proof-Verbrauch, signierten Kontext und Integrationsergebnisse.
Debug-Log im Bereich Werkzeuge mit UTC-Zeitstempeln, Request-Korrelations-IDs, sicherer Prüfung von Response-Feldern, HTTP-Status, Laufzeit und Proof-Contract-Checks.
Downloadbare JSON-Diagnoseberichte und eine geschützte Funktion zum Löschen des Logs.
Protokollierung von Token-Vorhandensein, Länge und irreversiblem kurzem Fingerprint ohne Speicherung von Zugangsdaten oder vollständigen Tokens.

Debug-Einträge entfernen Zugangsdaten, Autorisierungsmaterial, Cookies, Nonces, Site Keys, Secret Keys sowie vollständige Challenge-, Context- und Verification-Tokens.
Die Verifikation bleibt fail-closed; dieses Diagnose-Release schwächt den Proof-Vertrag nicht und umgeht keine serverseitige Prüfung.

Der autoritative Browser-verificationToken wird getrennt von veränderbarem Login-Formular-Markup gespeichert.
Signierter Kontext und versteckte Verification-Felder werden neu erstellt und synchronisiert, wenn ein anderes Login- oder Security-Plugin das Formular-DOM verändert.
Eine native formdata-Serialisierungs-Bridge stellt sicher, dass WordPress-Login-POST-Anfragen stets den aktuellen TrueSift-Proof enthalten.
Der Submit bleibt blockiert, solange der aktuelle Proof nicht sowohl verifiziert als auch serialisierbar ist.

Die TrueSift-Verifikationskomponente wird innerhalb von woocommerce/checkout-actions-block unmittelbar vor der Place-order-Aktion gerendert.
verificationToken und der signierte WordPress-contextToken werden über den Checkout-Store-Extension-Namespace truesift veröffentlicht.
Checkout-Block-Validierung über wc.blocksCheckoutEvents.onCheckoutValidation, einschließlich durch Express Payment ausgelöster Checkout-Validierung.
Checkout-Block-Proofs werden über die Store-API-Grenze validiert und atomar verbraucht, bevor WooCommerce mit der Bestellverarbeitung beginnt.
Nach Verarbeitungsfehlern im Checkout Block wird TrueSift zurückgesetzt und ein neuer Proof verlangt.
Kompatibilität mit cart_checkout_blocks wird über WooCommerce FeaturesUtil deklariert.

Die WooCommerce-Checkout-Option in der Administration wurde umbenannt, damit klar ist, dass eine Einstellung sowohl klassischen als auch Block-Checkout schützt.

Die offizielle TrueSift-Browser-Laufzeit wird vor der Seitenausgabe geladen, wenn der abgefragte Beitrag den Shortcode [truesift] enthält.
Standalone-Shortcode-Seiten wurden korrigiert, bei denen das Mount-Markup vorhanden war, aber die spät eingebundene SDK-Laufzeit und Inline-Konfiguration durch Theme oder Optimierungs-Stack nicht zuverlässig ausgegeben wurden.
Das bestehende Enqueue beim Shortcode-Rendering bleibt als Fallback für dynamisch erzeugte Shortcode-Inhalte erhalten.

Der Einstiegspunkt des WordPress-Browser-Bundles wurde korrigiert, sodass die offizielle TrueSiftCheck-Komponente geladen wird, ohne optionale SDK-Exporte vorzeitig aufzulösen, die nicht Teil der WordPress-Laufzeit sind.
SDK- und Adapter-Assets für den Login-Screen werden im Dokument-Head geladen.
Robuste automatische Mounts für #loginform, #registerform und #lostpasswordform wurden ergänzt.
Ein einfacher [truesift]-Shortcode kann die offizielle visuelle Prüfung im Standalone-Modus rendern, wenn er nicht innerhalb eines Formulars platziert ist.
PHP-Hook-Rendering bleibt der primäre Integrationsweg, während doppelte Mounts verhindert werden.

Alle wesentlichen Produktionsänderungen am TrueSift-WordPress-Plugin werden hier dokumentiert.

TrueSift-Browser-Laufzeit, WordPress-Abhängigkeit wp-element, Konfiguration und Stylesheet werden während login_enqueue_scripts geladen, bevor der Head der Login-Seite ausgegeben wird.
Sichtbares Widget-Rendering und Schutz des Submit-Buttons auf nativen WordPress-Seiten für Login, Registrierung und Passwort-Reset wurden wiederhergestellt.

WordPress-native TrueSift-Administration unter Einstellungen.
Verschlüsselte Speicherung der Site-Zugangsdaten mit Unterstützung für Konstanten in wp-config.php.
Live-Vorschauen ohne Netzwerkzugriff für Checkbox-, Banner-, Inline- und Badge-Layouts.
Globale Einstellungen für Theme, Sprache, Größe, Appearance, Timeout und Verfügbarkeitsrichtlinie.
Sichere lokale REST-Bridges für Challenge und Browser-Verifikation.
Serverseitige Proof-Validierung mit Bindung an Action, Path und Origin.
Atomarer einmaliger Token-Verbrauch und Schutz vor Replay.
Integrationen für WordPress-Login, Registrierung, Passwort-Reset und Kommentare.
Integrationen für WooCommerce-Login, Registrierung, klassischen Checkout und Produktbewertungen.
Integrationen für Contact Form 7, WPForms, Fluent Forms und Elementor Pro Forms.
Manueller [truesift]-Shortcode und PHP-Helper truesift_verify_request().
Import und Export der Einstellungen ohne geheime Zugangsdaten.
Verbindungsdiagnose, Datenschutz-Hinweise, sichere Logs und Deinstallationskontrollen.

Browserwerte allowed, decision, score, status, failOpen, challengeId, action, path und origin autorisieren niemals eine geschützte PHP-Aktion.
Der TrueSift Secret Key bleibt serverseitig.
Normale Proof-Akzeptanz erfordert allowed: true, decision: allow und consumed: true.
Ungültige, abgelaufene, erneut verwendete, nicht passende, mit review bewertete und blockierte Proofs werden abgewiesen.