—Системен статус
Документация

WordPress интеграция

Вграден поток

text
Защитена WordPress форма
→ локален POST /wp-json/truesift/v1/challenge
→ TrueSift POST /api/v1/botguard/challenge
→ локален POST /wp-json/truesift/v1/verify
→ TrueSift POST /api/v1/botguard/verify
→ браузърът получава еднократен verificationToken
→ защитената форма изпраща verificationToken + подписан truesift_context
→ WordPress PHP извиква POST /api/v1/botguard/proof/verify
→ защитеното действие продължава само ако довереният proof го разреши

Резултатът в браузъра е само UI състояние. PHP никога не разрешава операция на базата на подадени от браузъра полета allowed, decision, score, status, failOpen, challengeId, action, path или origin.

Ръчен shortcode

text
[truesift]

Допълнителни selectors:

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

Допълнителни официални display стойности:

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

Собствен 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.

Helper-ът прочита truesift_verification_token и truesift_context от form data или JSON. Той консумира proof-а атомарно и кешира доверения резултат само за текущата PHP заявка, така че няколко validation hooks в една и съща заявка да не използват токена повторно.

Собствено render-ване от PHP

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

Собствените действия трябва да продължат да използват официалния action, конфигуриран в Настройки → TrueSift, освен ако TrueSift site contract изрично не дефинира различен action.

WooCommerce Checkout Block

Една и съща настройка woo_checkout защитава и двете checkout архитектури.

При Checkout Block TrueSift се render-ва непосредствено преди Checkout Actions блока. Browser bridge-ът публикува само следните стойности в Checkout Store extension namespace truesift:

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

Границата rest_authentication_errors валидира и консумира proof-а само за ефективната финална заявка POST /wc/store[/vN]/checkout. WordPress REST method overrides се разрешават със същия приоритет като в WP_REST_Server, затова WooCommerce draft updates като PUT /checkout остават update заявки дори когато браузърът ги транспортира технически като HTTP POST с _method или X-HTTP-Method-Override. Тези update заявки не консумират TrueSift proof.

Липсващ, невалиден, изтекъл, повторно използван, несъответстващ, оценен с review или блокиран proof спира Store API checkout обработката при реалната финална POST заявка. След грешка при checkout обработката клиентът изчиства extension data и стартира нова TrueSift верификация, защото предишният proof може вече да е консумиран.