WordPress-Integration

Integrierter Ablauf

text

Geschütztes WordPress-Formular
→ lokaler POST /wp-json/truesift/v1/challenge
→ TrueSift POST /api/v1/botguard/challenge
→ lokaler POST /wp-json/truesift/v1/verify
→ TrueSift POST /api/v1/botguard/verify
→ Browser erhält einmaligen verificationToken
→ geschütztes Formular sendet verificationToken + signierten truesift_context
→ WordPress PHP ruft POST /api/v1/botguard/proof/verify auf
→ geschützte Aktion wird nur fortgesetzt, wenn der vertrauenswürdige Proof sie erlaubt

Das Browser-Ergebnis ist ausschließlich UI-Zustand. PHP autorisiert keine Aktion anhand der vom Browser gelieferten Felder allowed, decision, score, status, failOpen, challengeId, action, path oder origin.

Manueller Shortcode

text

[truesift]

Optionale Selektoren:

text

[truesift form_selector="#contact-form" button_selector="button[type=submit]"]

Optionale offizielle Darstellungswerte:

text

[truesift visual_mode="banner" size="flexible" theme="auto" locale="auto" appearance="always"]

Eigener PHP-Handler

php

$proof = truesift_verify_request();

if (is_wp_error($proof)) {
    wp_die(
        esc_html($proof->get_error_message()),
        esc_html__('Security check failed', 'my-plugin'),
        array('response' => 403)
    );
}

if (empty($proof['allowed'])) {
    wp_die(esc_html__('Forbidden', 'my-plugin'), 403);
}

// Perform the protected business operation here.

Der Helper liest truesift_verification_token und truesift_context aus Formulardaten oder JSON. Er verbraucht den Proof atomar und cached das vertrauenswürdige Ergebnis ausschließlich für die aktuelle PHP-Anfrage. Dadurch führen mehrere Validierungs-Hooks innerhalb derselben Anfrage nicht zu einer erneuten Verwendung des Tokens.

Eigenes Rendering aus PHP

php

echo truesift_render_widget(array(
    'source' => 'my-integration',
    'form_selector' => '#my-form',
    'button_selector' => '#my-submit',
));

Eigene Aktionen sollten weiterhin die in Einstellungen → TrueSift konfigurierte offizielle Action verwenden, sofern der TrueSift-Site-Vertrag nicht bewusst eine andere Action definiert.

WooCommerce Checkout Block

Die Einstellung woo_checkout schützt beide Checkout-Architekturen.

Beim Checkout Block wird TrueSift unmittelbar vor dem Checkout-Actions-Block gerendert. Die Browser-Bridge veröffentlicht unter dem Checkout-Store-Extension-Namespace truesift ausschließlich diese Werte:

json

{
  "verificationToken": "opaque one-time token",
  "contextToken": "signed WordPress form context"
}

Die Grenze rest_authentication_errors validiert und verbraucht den Proof ausschließlich für die effektive finale Anfrage POST /wc/store[/vN]/checkout. WordPress-REST-Method-Overrides werden mit derselben Priorität wie in WP_REST_Server aufgelöst. Dadurch bleiben WooCommerce-Draft-Updates wie PUT /checkout echte Update-Anfragen, selbst wenn der Browser sie technisch als HTTP POST mit _method oder X-HTTP-Method-Override transportiert. Diese Updates verbrauchen keinen TrueSift-Proof.

Fehlende, ungültige, abgelaufene, erneut verwendete, nicht passende, mit review bewertete oder blockierte Proofs stoppen beim tatsächlichen finalen POST die Verarbeitung durch die Store API. Nach einem Fehler während der Checkout-Verarbeitung löscht der Client die Extension-Daten und startet eine neue TrueSift-Verifikation, da der vorherige Proof bereits verbraucht sein kann.