Init Void Shield – Zero-DB, Honeypot, Anti-Spam

Mô tả

Init Void Shield bảo vệ form bình luận WordPress, form đăng nhập/đăng ký/quên mật khẩu mặc định, và các plugin form phổ biến bằng cơ chế bảo vệ honeypot nhiều lớp không cần bảng cơ sở dữ liệu, không JavaScript bên ngoài, và không gây khó chịu cho người dùng.

Plugin này là một phần của Init Plugin Suite — bộ sưu tập các công cụ WordPress tối giản, nhanh, và hướng tới lập trình viên.

Kho GitHub: https://github.com/brokensmile2103/init-void-shield

Công cụ honeypot cốt lõi (luôn bật cho bình luận):

  1. Tên trường động — được suy ra từ ngữ cảnh + salt của site (cộng thêm tiền tố tùy chỉnh tùy chọn) để bot không thể viết cứng tên trường.
  2. Honeypot ẩn bằng CSS — một trường văn bản và một ô đánh dấu bị ẩn bằng các kỹ thuật CSS luân phiên (không bao giờ dùng display:none hay visibility:hidden, hai mẫu mà bot nhận biết CSS đặc biệt tìm kiếm và bỏ qua) mà bot điền nhưng con người không bao giờ thấy. Trường văn bản cũng được đánh dấu readonly, nên trình duyệt và trình quản lý mật khẩu tự động điền (Chrome, lời nhắc mật khẩu đã lưu, và tương tự) cũng không bao giờ ghi vào đó — bot thu thập HTML thô hay điều khiển trình duyệt headless vẫn mắc bẫy y hệt.
  3. Token thời gian đã ký — mỗi form mang một timestamp + hash HMAC được xác minh phía máy chủ bằng hash_equals() để ngăn tấn công đo thời gian. Các lượt gửi dưới ngưỡng tối thiểu bị từ chối; form đăng nhập/đăng ký/dạng tài khoản khác dùng ngưỡng riêng, ngắn hơn theo mặc định (xem Thời gian gửi tối thiểu cho form tài khoản), vì việc trình duyệt tự động điền thông tin đã lưu cho phép một người truy cập thật gửi nhanh hơn so với gõ một bình luận từ đầu.
  4. Xác minh JavaScript + trình duyệt headless — một bằng chứng JS đã ký, riêng theo từng form được chèn sau một độ trễ có thể cấu hình (cộng thêm một khoảng jitter ngẫu nhiên nhỏ, để thời gian chờ chính xác không thể đọc được từ mã nguồn trang và canh thời điểm), và script đánh dấu các tín hiệu tự động hóa phổ biến (navigator.webdriver, cửa sổ trình duyệt kích thước 0, HeadlessChrome/PhantomJS, dấu vết Selenium/ChromeDriver) thu được từ các phiên Selenium/Puppeteer/Playwright thật. Bằng chứng được gắn với token thời gian riêng của form và không bao giờ xuất hiện dưới dạng văn bản thuần trong trang, nên một bot thu thập HTML và phát lại các giá trị ẩn không thể tạo ra nó. Crawler tĩnh, bot tức thì, và trình duyệt headless không ẩn danh đều bị bắt; người dùng thật thì không.
  5. Submit Hold — trên các form đăng nhập, đăng ký, bình luận, và các form khác gửi không dùng AJAX, một người truy cập nhấp gửi trước khi lớp bảo vệ sẵn sàng (thường ngay sau khi trình duyệt tự động điền mật khẩu đã lưu) sẽ được giữ lại trong chốc lát và gửi tự động khi sẵn sàng, thay vì bị từ chối. Không có gì được nới lỏng ở phía máy chủ.
  6. Phát hiện User-Agent không phải trình duyệt — từ chối các lượt gửi có User-Agent nhận diện là một client HTTP dạng script (curl, Python requests, Go, Scrapy, và tương tự) thay vì một trình duyệt thật, bắt được các bot bỏ qua hoàn toàn JavaScript và chỉ đơn giản phát lại các trường form tĩnh. Bật theo mặc định; danh sách chữ ký có thể tùy chỉnh.
  7. Chặn gửi liên trang — từ chối một lượt gửi mà chính trình duyệt báo cáo là gửi từ một website khác (Sec-Fetch-Site: cross-site), một header mà script trên trang không thể giả mạo và các tiện ích quyền riêng tư không loại bỏ. Một yêu cầu không có header này không bao giờ bị kiểm tra này từ chối. Bật theo mặc định.
  8. Chặn bình luận qua REST API (tùy chọn) — từ chối các bình luận gửi trực tiếp qua endpoint REST wp/v2/comments, mà các lớp dựa trên form cổ điển không thể bao trùm vì các yêu cầu đó không bao giờ mang trường honeypot hay token.
  9. Yêu cầu Referer cùng site (tùy chọn) — từ chối một lượt gửi bình luận có header Referer bị thiếu hoặc trỏ đến nơi khác, bắt được các bot gửi trực tiếp đến endpoint bình luận. Tắt theo mặc định và được công khai như một sự đánh đổi, vì một số trình duyệt tập trung vào quyền riêng tư loại bỏ Referer ngay cả trên các lượt gửi cùng site thật.
  10. Filter nội dung bình luận (tùy chọn) — số liên kết tối đa mỗi bình luận, chặn liên kết BBCode, và chặn địa chỉ web trong tên tác giả. Khác với các lớp hành vi, những filter này đọc thứ thực sự được viết ra, nên chúng cũng bắt được spam được đăng bởi một người thật hoặc trình duyệt thật — kể cả bình luận wpDiscuz, mà các lớp honeypot không thể thấy.

Mục tiêu thiết kế chính:

  • Không gây rối cơ sở dữ liệu (không bảng, không dòng; thống kê dùng một tùy chọn không tự tải duy nhất)
  • Không gọi JS/CDN bên ngoài
  • Không CAPTCHA, không câu đố, không làm gián đoạn người dùng
  • Người dùng đã đăng nhập tự động được bỏ qua trên form bình luận (có thể ghi đè tùy chọn trong cài đặt)
  • Mọi lớp bảo vệ ngoài form bình luận cốt lõi đều là tùy chọn tham gia — không có form mới nào âm thầm được bảo vệ khi bạn cập nhật
  • Bot nhận được HTTP 200 OK trên form bình luận nên chúng nghĩ đã thành công và bỏ đi

Filter

Tài liệu tham khảo ngắn về các filter dành cho lập trình viên đi kèm plugin (tất cả đều là filter WordPress tiêu chuẩn, thêm bằng add_filter()):

  • init_plugin_suite_void_shield_skip_verification — bỏ qua việc xác minh form bình luận cho một yêu cầu.
  • init_plugin_suite_void_shield_skip_login_verification / _register_verification / _lostpassword_verification / _multisite_signup_verification — chủ động tắt một lớp bảo vệ Form lõi WordPress riêng lẻ, ghi đè công tắc trên trang cài đặt.
  • init_plugin_suite_void_shield_login_scope_exempt — ghi đè cơ chế suy đoán dựa trên Referer dùng bởi Login Guard Scope “chỉ wp-login.php”.
  • init_plugin_suite_void_shield_honeypot_html — lọc khối HTML honeypot đã dựng; nhận chuỗi ngữ cảnh làm tham số thứ hai.
  • init_plugin_suite_void_shield_kill_response_message / _title / _code — tùy chỉnh phản hồi “giết mềm” hiển thị cho bot trên form bình luận.
  • init_plugin_suite_void_shield_min_time / _max_time / _js_delay — ghi đè các ngưỡng Thời gian gửi tối thiểu, Tuổi token tối đa, và Độ trễ Token JS.
  • init_plugin_suite_void_shield_hidden_style_variants — tùy chỉnh tập hợp kỹ thuật CSS dùng để ẩn các trường honeypot.
  • init_plugin_suite_void_shield_{context}_blocked_message — tùy chỉnh thông báo từ chối cho một lớp bảo vệ cụ thể (ví dụ ..._login_blocked_message, ..._woocommerce_blocked_message, ..._bbpress_blocked_message).
  • init_plugin_suite_void_shield_blocked_user_agent_signatures — tùy chỉnh danh sách chuỗi con User-Agent không phải trình duyệt được kiểm tra bởi Chặn User Agent không phải trình duyệt.
  • init_plugin_suite_void_shield_js_delay_jitter_max — ghi đè khoảng jitter ngẫu nhiên tối đa (mili giây) thêm vào bên trên Độ trễ Token JavaScript.
  • init_plugin_suite_void_shield_min_interaction_delay — ghi đè thời gian tối thiểu (mili giây) phải trôi qua trước khi một sự kiện Yêu cầu tương tác người dùng thật được chấp nhận.
  • init_plugin_suite_void_shield_referer_exempt — chủ động loại trừ một yêu cầu khỏi kiểm tra Yêu cầu Referer cùng site bất kể công tắc trên trang cài đặt.
  • init_plugin_suite_void_shield_cross_site_exempt — chủ động loại trừ một yêu cầu khỏi kiểm tra Chặn gửi liên trang; nhận ngữ cảnh bảo vệ làm tham số thứ hai.
  • init_plugin_suite_void_shield_submit_hold_enabled — bật hoặc tắt Submit Hold cho một ngữ cảnh bảo vệ cụ thể (ví dụ cho một form gửi kiểu gốc tùy chỉnh được thêm qua init_plugin_suite_void_shield_build_guard_markup()).
  • init_plugin_suite_void_shield_submit_hold_fetch_wait — thời gian tối đa (mili giây) Submit Hold chờ một yêu cầu Lazy Fetch đang chờ xử lý. Mặc định 4000.
  • init_plugin_suite_void_shield_skip_content_filters — bỏ qua các filter nội dung bình luận cho một yêu cầu.
  • init_plugin_suite_void_shield_comment_content_violation — thêm quy tắc nội dung bình luận riêng của bạn: trả về một khóa lý do để chặn bình luận, hoặc chuỗi rỗng để cho phép.

Giấy phép

Plugin này được cấp phép theo GPLv2 hoặc phiên bản mới hơn.

Ảnh màn hình

Cài đặt

  1. Tải thư mục plugin lên /wp-content/plugins/
  2. Kích hoạt qua Plugins Init Void Shield
  3. Vào Settings Init Void Shield để xem lại hoặc điều chỉnh các ngưỡng, và để tham gia các lớp bảo vệ form lõi WordPress hoặc bất kỳ tích hợp plugin form nào bạn dùng

Hỏi đáp

Plugin có hoạt động với trình dựng trang hay form bình luận tùy chỉnh không?

Plugin móc vào comment_form_after_fields. Nếu theme của bạn dùng form tùy chỉnh, bạn có thể cần điều chỉnh hook hoặc gọi thủ công hàm hiển thị.

Tôi có thể dùng plugin này cùng với Akismet hay các plugin chống spam khác không?

Có. Init Void Shield đóng vai trò tuyến phòng thủ đầu tiên. Các plugin khác có thể đóng vai trò lớp thứ hai.

Tính năng này có chặn người dùng hợp lệ không?

Không. Người dùng đã đăng nhập được bỏ qua theo mặc định trên form bình luận. Khách chỉ cần chờ vài giây giữa lúc tải trang và gửi — điều mà mọi con người tự nhiên làm.

Tôi có thể buộc xác minh cho người dùng đã đăng nhập không?

Có. Bật Áp dụng cho người dùng đã đăng nhập trong cài đặt nếu site của bạn có đăng ký mở hoặc thành viên không đáng tin cậy.

Tính năng này có bảo vệ bình luận gửi qua REST API không?

Không, theo mặc định. Các lớp cốt lõi chỉ chạy trên form bình luận cổ điển (preprocess_comment); các bình luận gửi trực tiếp đến wp/v2/comments không bao giờ mang honeypot hay token JS, nên các kiểm tra đó không áp dụng. Cài đặt tùy chọn “Chặn bình luận qua REST API” có sẵn để đóng hoàn toàn endpoint đó nếu bạn không dùng ứng dụng headless hay client REST hợp lệ khác cho bình luận.

Các lớp bảo vệ đăng nhập/đăng ký/quên mật khẩu của WordPress có bật theo mặc định không?

Không, cả ba đều tắt theo mặc định vì chúng bảo vệ chính việc xác thực. Bật riêng từng cái trong Form lõi WordPress trong cài đặt, và xác nhận luồng đăng nhập của bạn vẫn hoạt động sau đó. Mỗi lớp bảo vệ bao trùm mã đánh dấu form mặc định của WordPress tại wp-login.php, và lớp bảo vệ đăng nhập cũng bao trùm wp_login_form() khi dùng ở frontend (ví dụ một widget hoặc mẫu theme), trừ khi bạn đặt Login Guard Scope thành “chỉ wp-login.php” — xem câu hỏi tiếp theo. Một trang đăng nhập/plugin tùy chỉnh, hoặc luồng đăng ký wp-signup.php của Multisite, dựng mã đánh dấu khác và không được bao trùm. Mỗi lớp bảo vệ cũng có thể bị chủ động tắt theo từng yêu cầu bằng filter riêng (init_plugin_suite_void_shield_skip_login_verification, ..._skip_register_verification, ..._skip_lostpassword_verification), ưu tiên hơn công tắc trên trang cài đặt.

Login Guard Scope là gì?

Theo mặc định (“Mọi nơi”), Login Guard bảo vệ cả form wp-login.php gốc lẫn bất kỳ cách dùng wp_login_form() ở frontend nào (ví dụ một trang đăng nhập tùy chỉnh, widget, hoặc modal). Nếu form frontend đó nằm trên một trang mà plugin cache của bạn có thể phục vụ dữ liệu cũ, hãy chuyển phạm vi sang “chỉ wp-login.php” để hoàn toàn không bảo vệ nó thay vì mạo hiểm việc đăng nhập của một người truy cập thật bị từ chối — form wp-login.php gốc vẫn được bảo vệ đầy đủ dù thế nào. Tính năng này dùng header Referer làm cơ chế suy đoán để phân biệt hai form, mà một bot quyết tâm có thể giả mạo, nên đây là một sự đánh đổi có chủ ý: chỉ chuyển khỏi “Mọi nơi” nếu bạn đã gặp phải tình huống lưu đệm cụ thể này.

Các tích hợp Contact Form 7 / WPForms / Gravity Forms có bật theo mặc định không?

Không. Mỗi tính năng đều tắt theo mặc định và chỉ có hiệu lực nếu plugin tương ứng đang hoạt động — trang cài đặt hiển thị trạng thái “đã phát hiện / chưa phát hiện” bên cạnh mỗi công tắc.

Các tích hợp WooCommerce / bbPress / BuddyPress có bật theo mặc định không?

Không, giống như các tích hợp khác: mỗi tính năng đều tắt theo mặc định và chỉ có hiệu lực nếu plugin tương ứng đang hoạt động. WooCommerce bảo vệ form đăng ký “My Account”, và tùy chọn bảo vệ form đăng nhập WooCommerce (My Account và lời nhắc đăng nhập lúc thanh toán) và form quên mật khẩu; bbPress bảo vệ các form Chủ đề mới và Trả lời; BuddyPress bảo vệ form đăng ký. Lớp bảo vệ đăng ký Multisite (wp-signup.php) chỉ có hiệu lực trên bản cài Multisite và cũng tắt theo mặc định.

Tại sao Ninja Forms hay Forminator không được hỗ trợ?

Cả hai đều dựng form của mình phía client và thu thập dữ liệu gửi qua mô hình trường JavaScript riêng của họ thay vì tuần tự hóa toàn bộ phần tử <form>, nên một trường honeypot chỉ đơn giản thêm vào trang sẽ không được gửi đến máy chủ một cách đáng tin cậy — nó sẽ trông giống như bảo vệ nhưng thực ra không làm gì cả. Cả hai cũng đã có sẵn trường honeypot tích hợp riêng của họ. Việc hỗ trợ có thể được xem xét lại nếu có một hook đáng tin cậy khả dụng.

Plugin có hoạt động với wpDiscuz không?

wpDiscuz dựng các lượt gửi bình luận của nó từ một tập trường cố định thay vì tuần tự hóa toàn bộ form, nên các kiểm tra của plugin này không bao giờ có thể thấy hoặc xác minh chúng. Khi wpDiscuz được phát hiện đang hoạt động, bình luận của nó sẽ tự động được loại trừ khỏi việc xác minh thay vì bị từ chối — đây là một cách bỏ qua để tương thích, không phải một lớp bảo vệ bổ sung.

Cài đặt Tuổi token tối đa là gì?

Mỗi lớp bảo vệ phát hành một token đã ký có hiệu lực trong một khung thời gian giới hạn: quá nhanh (dưới Thời gian gửi tối thiểu) và quá cũ (trên Tuổi token tối đa) đều bị từ chối. Giới hạn trên tồn tại để một token không thể bị bắt lấy một lần rồi phát lại vô thời hạn; mặc định 1 giờ đủ rộng rãi cho một người truy cập từ từ điền form. Tăng nó (lên đến 30 ngày) nếu người truy cập hợp lệ trên site của bạn thường mất nhiều thời gian hơn thế, hoặc nếu site của bạn dùng cache toàn trang — xem câu hỏi tiếp theo.

Site của tôi dùng cache toàn trang mạnh và bình luận hợp lệ đang bị từ chối với lý do “đã hết hạn” — tôi phải làm gì?

Trên một trang đã lưu đệm, token thời gian có sẵn trong HTML phản ánh thời điểm trang được lưu đệm, không phải thời điểm một người truy cập thật tải nó. Nếu thời gian tồn tại của bộ nhớ đệm của bạn dài, khoảng cách đó có thể vượt quá Tuổi token tối đa. Có hai tùy chọn, mỗi cái tự hoạt động độc lập: tăng Tuổi token tối đa để bao trùm thoải mái thời gian tồn tại bộ nhớ đệm của bạn, hoặc bật Lazy Fetch trong Bảo vệ nâng cao, làm mới token phía client ngay sau khi trang thực sự tải, nên thời gian luôn được đo từ lượt truy cập thật bất kể tuổi bộ nhớ đệm.

Lazy Fetch làm gì, và có an toàn không?

Khi bật, một yêu cầu JavaScript cùng nguồn nhỏ (không jQuery, không dịch vụ bên ngoài) lấy một token thời gian mới, đã ký đúng ngay sau khi trang tải, và ghi đè lên token đã có sẵn từ lúc dựng trang. Nó không có trạng thái — endpoint chỉ tính lại chính xác hash đã ký mà trang vốn sẽ đã hiển thị, và chỉ được đăng ký khi Lazy Fetch đang được bật. Nếu yêu cầu thất bại, hoặc JavaScript không khả dụng, token có sẵn ban đầu được dùng nguyên vẹn, y hệt như trước khi có Lazy Fetch — nên việc bật nó chỉ có thể giúp ích, không bao giờ tạo ra chế độ lỗi mới. Tắt theo mặc định; áp dụng cho mọi form được bảo vệ, không chỉ bình luận.

Tôi đã cập nhật từ phiên bản cũ hơn và Thời gian gửi tối thiểu / Độ trễ Token JS không còn hoạt động như tôi nhớ — tại sao vậy?

Các phiên bản trước 1.4 có lỗi khiến hai cài đặt này được lưu đúng nhưng chưa bao giờ thực sự được đọc lại trong lúc xác minh, nên plugin luôn âm thầm áp dụng giá trị mặc định (3 giây / 1000ms) bất kể đã cấu hình gì. Phiên bản 1.4 sửa lỗi này, nên một giá trị tùy chỉnh bạn đặt trước đây giờ có thể lần đầu tiên được áp dụng thực sự. Đây là sửa lỗi, không phải giới hạn mới — chỉ cần kiểm tra lại cả hai giá trị trên trang cài đặt sau khi cập nhật.

“Yêu cầu tương tác người dùng thật” làm gì?

Khi bật, một lượt gửi chỉ được chấp nhận nếu trình duyệt ghi nhận ít nhất một sự kiện chuột, bàn phím, chạm, hoặc cuộn thật trước khi token JS được kích hoạt — và sự kiện đó chỉ được tính khi một độ trễ tối thiểu ngắn riêng của nó đã trôi qua, nên một bot không thể đáp ứng nó bằng cách bắn một sự kiện giả ngay khi trang tải. Tính năng này nhắm vào các bot chờ hết Độ trễ Token JavaScript thay vì một lượt truy cập trang thật. Tính năng này tắt theo mặc định và hoạt động tốt nhất khi kết hợp với độ trễ JS ít nhất 1-2 giây.

“Chặn User Agent không phải trình duyệt” làm gì, và có an toàn khi để bật không?

Tính năng này từ chối bất kỳ lượt gửi nào có header User-Agent nhận diện là một client HTTP dạng script — curl, thư viện requests của Python, client mặc định của Go, Scrapy, PostmanRuntime, và tương tự — thay vì một trình duyệt thật. Tính năng này bật theo mặc định và là một trong những kiểm tra an toàn nhất của plugin: mọi trình duyệt thật, kể cả mọi trình duyệt lớn và các biến thể di động của chúng, đều gửi User-Agent trình duyệt riêng biệt, không bao giờ là một trong những giá trị mặc định của các thư viện này. Nó đặc biệt bắt được một bot hoàn toàn không chạy JavaScript — loại phân tích HTML tĩnh, tránh các trường honeypot, và phát lại token thời gian/hash đã có sẵn — mà các lớp honeypot và JS không thể tự thấy được. Nếu bạn chạy script hợp lệ của riêng bạn nhắm vào form bình luận (ví dụ một công cụ kiểm thử nội bộ), hãy cho nó User-Agent trình duyệt bình thường hoặc dùng filter init_plugin_suite_void_shield_skip_verification cho yêu cầu đó.

“Yêu cầu Referer cùng site” làm gì?

Khi bật, một lượt gửi bình luận sẽ bị từ chối nếu header Referer bị thiếu hoặc trỏ đến một tên miền khác với tên miền của bạn — điều này bắt được một bot gửi trực tiếp đến endpoint bình luận mà không thực sự tải trang. Tính năng này tắt theo mặc định và được công khai như một sự đánh đổi, giống như cơ chế suy đoán Referer của Login Guard Scope: một số trình duyệt và tiện ích tập trung vào quyền riêng tư loại bỏ header Referer ngay cả trên lượt gửi cùng site thật, và kiểm tra này không thể phân biệt điều đó với bot. Chỉ bật tính năng này sau khi xác nhận nó không ảnh hưởng đến người bình luận thật trên site của bạn, và coi nó như một lớp bổ sung bên trên các lớp khác chứ không phải thay thế chúng. Có sẵn filter init_plugin_suite_void_shield_referer_exempt nếu bạn cần loại trừ các yêu cầu cụ thể (ví dụ một proxy hoặc thiết lập cache hợp lệ loại bỏ Referer).

Tôi có thể thay đổi tên trường honeypot không?

Có. Đặt Tiền tố trường tùy chỉnh trong Bảo vệ nâng cao. Tên trường vẫn được suy ra động theo ngữ cảnh và salt của site bên trên tiền tố đó.

Việc phát hiện trình duyệt headless có gọi dịch vụ bên ngoài nào không?

Không. Nó chỉ đọc một vài thuộc tính trên chính thiết bị của người truy cập (navigator.webdriver, kích thước cửa sổ trình duyệt, chuỗi User-Agent, và các biến toàn cục/dấu hiệu mà chỉ framework tự động hóa mới chèn vào) — không có yêu cầu bên ngoài, không theo dõi.

Tính năng thống kê lưu trữ những gì?

Chỉ có các bộ đếm tổng hợp (tổng số, chi tiết theo kênh, chi tiết theo lý do chặn, và timestamp chặn cuối cùng) trong một tùy chọn không tự tải. Không có nhật ký theo từng lượt gửi, địa chỉ IP, hay dữ liệu cá nhân nào được ghi lại. Có thể tắt hoặc đặt lại từ trang cài đặt bất cứ lúc nào.

Widget bảng điều khiển có bật theo mặc định không?

Không. Bật Hiển thị widget bảng điều khiển trong Thống kê. Nó chỉ hiển thị cho người dùng có quyền quản lý tùy chọn, và chỉ hiện các bộ đếm tổng hợp giống như trang cài đặt (không có dữ liệu theo từng lượt gửi).

Tôi thấy lỗi cú pháp JavaScript trong console trình duyệt gần “lazyFetchEnabled”, và mọi bình luận đều bị từ chối — chuyện gì đang xảy ra?

Đây là một lỗi đã được sửa trong phiên bản 1.8: một số môi trường (bộ nén HTML, plugin đa ngôn ngữ, plugin bảo mật/lọc kết quả xuất, hoặc convert_chars() của chính WordPress) viết lại một ký tự & thô trong kết quả xuất trang thành &#038;, an toàn cho văn bản HTML thông thường nhưng làm hỏng JavaScript nguyên văn bên trong thẻ <script>, vì trình duyệt không bao giờ giải mã thực thể ở đó. Nếu bạn đang dùng 1.8 trở lên và vẫn thấy vấn đề này, vui lòng báo cáo kèm theo các plugin/theme đang hoạt động để xác định nguồn cụ thể.

Tại sao việc đăng nhập đôi khi mất thêm khoảng một giây sau khi cập nhật lên 1.11?

Đó là Submit Hold đang hoạt động. Nếu một người truy cập nhấp “Đăng nhập” trước khi lớp bảo vệ sẵn sàng — thường là vì trình duyệt tự động điền mật khẩu đã lưu và họ nhấp ngay — lượt gửi sẽ được giữ lại trong chốc lát (tối đa là Độ trễ Token JavaScript hoặc Thời gian gửi tối thiểu, tùy giá trị nào lớn hơn) rồi được gửi tự động. Trước 1.11, đăng nhập như vậy bị từ chối thẳng. Tính năng này áp dụng cho các form gửi không dùng AJAX: các form lõi của WordPress, bình luận, form tài khoản WooCommerce, bbPress, và BuddyPress. Contact Form 7, WPForms, và Gravity Forms gửi form của họ từ script riêng và không thay đổi.

Sau khi cập nhật lên 1.11, một số lượt gửi bị chặn với lý do “Invalid JS proof” — tại sao vậy?

Phiên bản 1.11 đã thay giá trị token JS cố định bằng một bằng chứng đã ký, riêng biệt cho mỗi lần dựng form. Một trang được phục vụ từ cache toàn trang được tạo trước khi cập nhật vẫn chứa script cũ, khiến các lượt gửi giờ thất bại kiểm tra đó. Hãy xóa bộ nhớ đệm trang của bạn (và mọi bộ nhớ đệm CDN) một lần sau khi cập nhật. Nếu lý do vẫn tiếp tục xuất hiện sau đó, đó là một bot.

“Chặn gửi liên trang” làm gì, và có an toàn khi để bật không?

Các trình duyệt hiện đại tự gắn header Sec-Fetch-Site vào mọi yêu cầu; script trên trang không thể đặt hay thay đổi nó. Một người truy cập thật gửi form trên site của bạn luôn gửi same-origin (hoặc same-site từ một trong các tên miền phụ của bạn). cross-site nghĩa là form được gửi từ một website khác — ví dụ một trang spam tự động gửi bản sao form của bạn — điều mà một người truy cập thật không bao giờ làm. Một yêu cầu không có header này (trình duyệt cũ, hoặc script đơn thuần) không bao giờ bị kiểm tra này từ chối, nên nó không thể tự tạo ra báo động giả. Trường hợp duy nhất cần tắt nó là khi một form ở tên miền không liên quan hợp lệ gửi đến site của bạn (ví dụ mạng Multisite với các subsite ở tên miền không liên quan dùng chung một form đăng nhập); filter init_plugin_suite_void_shield_cross_site_exempt có thể loại trừ các yêu cầu cụ thể thay thế.

Các filter nội dung bình luận làm gì?

Ba kiểm tra độc lập, tùy chọn tham gia trong Comments: Số liên kết tối đa mỗi bình luận (0 = tắt), Chặn liên kết BBCode (một cặp [url]…[/url] hoặc [link]…[/link] hoàn chỉnh, mà WordPress vốn không bao giờ hiển thị), và Chặn URL trong tên tác giả. Chúng bắt được spam mà một người thật hoặc trình duyệt thật đăng, điều mà các lớp bảo vệ hành vi không làm được, và chúng cũng áp dụng cho bình luận wpDiscuz. Pingback và trackback không bao giờ bị kiểm tra. Bình luận bị chặn nhận cùng phản hồi “giết mềm” như phần còn lại của lớp bảo vệ bình luận.

Lập trình viên có thể tùy chỉnh hành vi không?

Có. Xem mục Filter bên dưới để có danh sách đầy đủ, hoặc tài liệu trên GitHub để biết thêm chi tiết.

Đánh giá

Không có đánh giá nào cho plugin này.

Người đóng góp & Lập trình viên

“Init Void Shield – Zero-DB, Honeypot, Anti-Spam” là mã nguồn mở. Những người sau đã đóng góp vào plugin này.

Những người đóng góp

“Init Void Shield – Zero-DB, Honeypot, Anti-Spam” đã được dịch qua 1 ngôn ngữ. Cảm ơn những người tham gia dịch vì đóng góp của họ.

Dịch “Init Void Shield – Zero-DB, Honeypot, Anti-Spam” sang ngôn ngữ của bạn.

Muốn tham gia phát triển?

Duyệt code, check out SVN repository, hoặc theo dõi nhật ký phát triển qua RSS.

Nhật ký thay đổi

1.11 – 23 tháng 9, 2026

  • Đã sửa lỗi: một người truy cập thật vẫn có thể bị từ chối trên form Đăng nhập (và các form tài khoản khác) khi trình duyệt tự động điền mật khẩu đã lưu và họ nhấp “Đăng nhập” trong giây đầu tiên. Token JS trước đây chỉ tồn tại sau khi Độ trễ Token JavaScript đã trôi qua, và Thời gian gửi tối thiểu so sánh theo giây trọn vẹn, nên một cú nhấp như vậy bị đánh dấu là “Thiếu hoặc token JS không hợp lệ” hoặc “Gửi quá nhanh”. Đã thêm Submit Hold: trên các form gửi không dùng AJAX (form lõi WordPress, bình luận, form tài khoản WooCommerce, bbPress, BuddyPress), một lượt gửi sớm giờ được giữ lại trong chốc lát và gửi tự động khi lớp bảo vệ sẵn sàng, thay vì bị từ chối. Không có kiểm tra phía máy chủ nào bị nới lỏng — lượt gửi được giữ chỉ đơn giản đến khi nó thỏa mãn các kiểm tra đó. Tên/giá trị của nút đã nhấp được giữ nguyên, và các cú nhấp lặp lại trong lúc giữ chỉ tạo ra một lượt gửi duy nhất.
  • Bảo mật: token JS không còn là chuỗi cố định human_verified, vốn giống hệt nhau trên mọi site và có thể được một bot gửi mà không chạy bất kỳ JavaScript nào. Giờ nó là một bằng chứng đã ký gắn với token thời gian và ngữ cảnh riêng của form, được nhúng trong trang chỉ ở dạng đã niêm phong. Một lượt gửi mang bằng chứng bị thiếu, tĩnh, hoặc không khớp sẽ bị từ chối với lý do chặn mới “Invalid JS proof”. Lazy Fetch giờ làm mới bằng chứng cùng với token thời gian. Hãy xóa bộ nhớ đệm trang của bạn một lần sau khi cập nhật — các trang đã lưu đệm với script trước đó sẽ thất bại kiểm tra này.
  • Đã thêm Chặn gửi liên trang trong Bảo vệ nâng cao (bật theo mặc định): từ chối một lượt gửi mà chính trình duyệt báo cáo là gửi từ một website khác (Sec-Fetch-Site: cross-site). Một yêu cầu không có header này không bao giờ bị kiểm tra này từ chối. Có thể loại trừ theo từng yêu cầu qua init_plugin_suite_void_shield_cross_site_exempt.
  • Tăng cường Phát hiện trình duyệt headless: giờ cũng đánh dấu User-Agent HeadlessChrome/PhantomJS, các biến toàn cục tự động hóa DOM/Nightmare/PhantomJS, và dấu hiệu Selenium ChromeDriver.
  • Tăng cường Chặn User Agent không phải trình duyệt: đã thêm chữ ký HeadlessChrome, PhantomJS, HTTPX, aiohttp, axios, undici, HTTPie, và Colly.
  • Đã thêm filter nội dung bình luận trong Comments (mỗi cái tùy chọn tham gia, tắt theo mặc định): Số liên kết tối đa mỗi bình luận, Chặn liên kết BBCode, và Chặn URL trong tên tác giả. Chúng cũng áp dụng cho bình luận wpDiscuz, mà các lớp honeypot không thể xác minh. Filter mới init_plugin_suite_void_shield_skip_content_filters và init_plugin_suite_void_shield_comment_content_violation (để thêm quy tắc riêng của bạn).
  • Đã thêm lớp bảo vệ Đăng nhập WooCommerce (My Account và lời nhắc đăng nhập lúc thanh toán) và Quên mật khẩu WooCommerce trong Tích hợp cộng đồng & Thương mại điện tử, cả hai đều tắt theo mặc định. Cả hai đều dùng Thời gian gửi tối thiểu cho form tài khoản và hưởng lợi từ Submit Hold.
  • Đã sửa lỗi: khi Bảo vệ form Quên mật khẩu được bật, mọi yêu cầu đặt lại mật khẩu WooCommerce trước đây đều bị từ chối, kể cả những yêu cầu hợp lệ, vì trình xử lý đặt lại của WooCommerce chạy cùng kiểm tra lõi nhưng form của nó không bao giờ mang các trường honeypot. Form quên mật khẩu WooCommerce giờ luôn được bảo vệ khi lớp bảo vệ Quên mật khẩu lõi được bật, và mỗi form được xác minh theo ngữ cảnh riêng của nó.
  • Đã sửa lỗi: việc gỡ cài đặt plugin trước đây để sót lại các tùy chọn Thời gian gửi tối thiểu cho form tài khoản, Yêu cầu Referer cùng site, và Chặn User Agent không phải trình duyệt.
  • Thống kê: các lượt chặn WooCommerce giờ được nhóm là “Form tài khoản WooCommerce”, với các lý do chặn mới cho các kiểm tra nêu trên.
  • Đã cập nhật bản dịch tiếng Việt và mẫu .pot cho các chuỗi mới.

1.10 – 14 tháng 9, 2026

  • Đã tổ chức lại màn hình Cài đặt: chuyển Thời gian gửi tối thiểu, Thời gian gửi tối thiểu cho form tài khoản, Độ trễ Token JavaScript, và Tuổi token tối đa ra khỏi “Comments” vào mục mới Timing & Token Engine, vì các cài đặt này được dùng chung bởi mọi form được bảo vệ, không chỉ bình luận. Không có tên cài đặt, giá trị, hay hành vi nào thay đổi.
  • Đã cập nhật bản dịch tiếng Việt và mẫu .pot cho các chuỗi mục mới.

1.9 – 10 tháng 9, 2026

  • Đã sửa lỗi: một người truy cập thật trên một form tự động điền (thường nhất là đăng nhập) trước đây có thể bị đánh dấu sai là “Không phát hiện tương tác thật” nếu bộ đếm giờ trễ JS kích hoạt ngay trước cú nhấp gửi của họ, ngay cả khi Yêu cầu tương tác người dùng thật hoạt động đúng như thiết kế. Giờ kết quả được kiểm tra lại tại thời điểm gửi và chỉ có thể nâng cấp một kết quả “không tương tác” đã được đánh dấu trước đó thành đã xác minh.
  • Đã thêm cài đặt riêng Thời gian gửi tối thiểu cho form tài khoản (mặc định 1 giây), dùng bởi các lớp bảo vệ Đăng nhập, Đăng ký, Quên mật khẩu, Đăng ký Multisite, đăng ký WooCommerce, và đăng ký BuddyPress thay vì Thời gian gửi tối thiểu chung — tự động điền cho phép một người truy cập thật gửi nhanh hơn so với gõ một bình luận. Đặt thành 0 để tắt kiểm tra này chỉ cho form tài khoản. Các filter init_plugin_suite_void_shield_min_time và _max_time giờ cũng nhận ngữ cảnh bảo vệ làm tham số thứ hai.
  • Đã tăng cường trường bẫy honeypot với readonly, để trình duyệt và trình quản lý mật khẩu tự động điền không bao giờ điền vào đó; khả năng bắt bot không bị ảnh hưởng.
  • Đã cập nhật bản dịch tiếng Việt và mẫu .pot cho các chuỗi cài đặt mới.

1.8 – 8 tháng 9, 2026

  • Đã sửa lỗi: một ký tự ‘&’ thô bên trong script honeypot trước đây có thể bị mã hóa thành thực thể HTML bởi một số môi trường (bộ nén HTML, plugin đa ngôn ngữ, plugin bảo mật/lọc kết quả xuất, hoặc convert_chars() của chính WordPress), biến && thành văn bản nguyên văn &#038;&#038; trên trang. Trình duyệt không bao giờ giải mã thực thể bên trong nội dung <script>, nên điều này làm hỏng hoàn toàn việc phân tích JS và âm thầm từ chối mọi lượt gửi. Script không còn phát ra bất kỳ ký tự & thô nào.
  • Đã sửa lỗi: bình luận của một người truy cập thật lần đầu trước đây có thể bị từ chối sai là chưa xác minh (chỉ thành công khi thử lại) trên các site dùng tối ưu “trì hoãn thực thi JavaScript”, vì script trước đây chỉ lắng nghe DOMContentLoaded, vốn đã kích hoạt trước khi một script bị trì hoãn như vậy chạy. Giờ nó kiểm tra document.readyState và chạy ngay nếu tài liệu đã qua trạng thái đang tải.
  • Đã thêm Phát hiện User-Agent không phải trình duyệt (bật theo mặc định): từ chối các lượt gửi có User-Agent nhận diện là một client HTTP dạng script (curl, Python requests, Go, Scrapy, và tương tự) thay vì một trình duyệt thật. Danh sách chữ ký có thể tùy chỉnh qua init_plugin_suite_void_shield_blocked_user_agent_signatures.
  • Đã thêm jitter Độ trễ Token JavaScript: giờ có thêm một khoảng thời gian ngẫu nhiên nhỏ (lên đến 400ms, có thể tùy chỉnh) bên trên độ trễ đã cấu hình để không thể đọc được từ mã nguồn trang và canh thời điểm.
  • Tăng cường Yêu cầu tương tác người dùng thật: một sự kiện tương tác giờ chỉ được tính khi một độ trễ tối thiểu ngắn đã trôi qua kể từ lúc script khởi tạo, khép lại một lỗ hổng mà một bot có thể thỏa mãn kiểm tra bằng một sự kiện giả tại lúc tải trang.
  • Đã thêm Yêu cầu Referer cùng site cho bình luận (tùy chọn tham gia, tắt theo mặc định): từ chối một lượt gửi có header Referer bị thiếu hoặc trỏ đến một site khác. Sự đánh đổi được công khai, cùng tinh thần với Login Guard Scope — một số trình duyệt tập trung vào quyền riêng tư loại bỏ Referer ngay cả trên các lượt gửi hợp lệ.
  • Đã loại bỏ mọi chú thích khỏi script honeypot nội tuyến được dựng trên mọi form được bảo vệ, vì nó in ra mã nguồn trang công khai ở mỗi lần tải. Lý giải giờ chỉ nằm trong mã nguồn PHP của plugin. Giảm khoảng một phần ba kích thước script được dựng.

1.7 – 1 tháng 9, 2026

  • Đã sửa lỗi: bộ làm sạch dữ liệu cho ô đánh dấu dùng chung trước đây coi bất kỳ giá trị nào có mặt là đã bật, khiến mọi ô đánh dấu chưa chọn bị lưu thành 1 ở lần lưu đầu tiên. Đã siết chặt để yêu cầu giá trị '1' rõ ràng trước khi coi một ô đánh dấu là đã bật.

1.6 – 30 tháng 8, 2026

  • Đã sửa lỗi: một cài đặt trước đây có thể bị kẹt vĩnh viễn ở giá trị đã lưu và âm thầm từ chối thay đổi khi Lưu — dễ nhận thấy nhất ở “Bật Init Void Shield”, vì một bản cài mới bắt đầu đã ở giá trị mặc định là đã chọn. Nguyên nhân do tham số default của register_setting(), kích hoạt một trường hợp biên của lõi WordPress trong update_option() khi giá trị của một cài đặt khớp với giá trị mặc định đó. Đã loại bỏ khỏi mọi cài đặt trong plugin này; giá trị mặc định hiển thị không bị ảnh hưởng.
  • Đã thêm tương thích tự động với wpDiscuz: wpDiscuz dựng các lượt gửi bình luận của nó từ một tập trường cố định thay vì tuần tự hóa form của nó, nên các kiểm tra của plugin này không bao giờ có thể thấy hoặc xác minh chúng. Khi wpDiscuz được phát hiện đang hoạt động, bình luận của nó giờ được âm thầm loại trừ khỏi việc xác minh thay vì bị từ chối.
  • Đã sửa lỗi: việc xác minh bình luận giờ xác định ID bài viết từ giá trị mà lõi WordPress đã phân tích, thay vì đọc lại trường POST comment_post_ID thô — không phải mọi form bình luận đều gửi nó dưới đúng tên đó.

1.5 – 30 tháng 8, 2026

  • Đã thêm Login Guard Scope: một tùy chọn mới “chỉ wp-login.php” cho Login Guard, ngừng hoàn toàn việc bảo vệ một cách dùng wp_login_form() ở frontend (ví dụ một trang đăng nhập tùy chỉnh, widget, hoặc modal) trong khi vẫn giữ bảo vệ đầy đủ trên form wp-login.php gốc. Dành cho các site mà form frontend đó nằm trên một trang mà cache toàn trang có thể phục vụ dữ liệu cũ; dùng header Referer làm cơ chế suy đoán để phân biệt hai form (một sự đánh đổi được công khai, không phải một đảm bảo mã hóa). Mặc định (“Mọi nơi”) không thay đổi và vẫn là tùy chọn mạnh nhất.
  • Đã nâng giới hạn Tuổi token tối đa từ 24 giờ lên 30 ngày, để các site có cache toàn trang tồn tại lâu dài có thể đặt một giá trị bao trùm thoải mái thời gian tồn tại bộ nhớ đệm của họ.
  • Đã thêm Lazy Fetch (Token an toàn với cache) trong Bảo vệ nâng cao (tắt theo mặc định): làm mới token thời gian qua một yêu cầu fetch() cùng nguồn nhỏ (JavaScript thuần, không jQuery, không dịch vụ bên ngoài) ngay khi trang thực sự tải, thay vì chỉ dựa vào giá trị có sẵn từ lúc dựng trang — vốn, trên một trang đã lưu đệm, phản ánh thời điểm bộ nhớ đệm được tạo ra chứ không phải thời điểm một người truy cập thật tải nó. Áp dụng cho mọi form được bảo vệ. Quay về dùng token có sẵn ban đầu nếu yêu cầu thất bại hoặc JavaScript không khả dụng, nên việc bật nó chỉ có thể giúp ích, không bao giờ tạo ra chế độ lỗi mới. Route REST của nó được đăng ký trong namespace initvoshi/v1, khớp với quy ước đặt tên dùng trên toàn Init Plugin Suite.

1.4 – 30 tháng 8, 2026

  • Bảo mật: token thời gian đã ký giờ được gắn với ngữ cảnh bảo vệ cụ thể mà nó được cấp cho (trước đây nó chỉ là một hàm của timestamp, nên một token hợp lệ bắt được từ một form — ví dụ một form bình luận công khai — về lý thuyết có thể bị phát lại nhắm vào một ngữ cảnh khác, nhạy cảm hơn, như lớp bảo vệ đăng nhập). Tên trường trước đây đã khác nhau theo ngữ cảnh, nhưng bản thân token thì không.
  • Bảo mật: đã thêm cài đặt Tuổi token tối đa (mặc định 1 giờ) để một token không thể bị bắt lấy một lần và lưu đệm để phát lại vô thời hạn. Các lượt gửi mang token cũ hơn mức này giờ bị từ chối với lý do chặn mới token_expired.
  • Đã sửa lỗi: các cài đặt Thời gian gửi tối thiểu và Độ trễ Token JavaScript trên trang cài đặt trước đây không thực sự được đọc trong lúc xác minh/hiển thị — mã luôn dùng giá trị mặc định của filter (3 giây / 1000ms) bất kể đã lưu gì. Giờ cả hai cài đặt đều có hiệu lực như mong đợi; các filter dành cho lập trình viên tương ứng vẫn áp dụng bên trên. Lưu ý cho người dùng hiện tại: nếu bạn trước đây đã thay đổi một trong hai giá trị khác với mặc định, nó trước đây âm thầm không có tác dụng — sau khi cập nhật nó giờ sẽ thực sự được áp dụng, nên đáng để xem lại cả hai giá trị trên trang cài đặt để xác nhận chúng vẫn là điều bạn muốn.
  • Đã thêm kiểm tra Yêu cầu tương tác người dùng thật tùy chọn trong Bảo vệ nâng cao (tắt theo mặc định): cũng yêu cầu ít nhất một sự kiện chuột, bàn phím, chạm, hoặc cuộn thật trước khi một lượt gửi được chấp nhận, để bắt các bot chỉ đơn giản chờ hết độ trễ JS mà không tương tác với trang.
  • Đã thêm tích hợp honeypot tùy chọn cho WooCommerce (form đăng ký My Account), bbPress (form Chủ đề mới và Trả lời), và BuddyPress (form đăng ký) — mỗi cái đều tắt theo mặc định, chỉ kích hoạt nếu plugin tương ứng đang hoạt động.
  • Đã thêm lớp bảo vệ đăng ký Multisite tùy chọn cho wp-signup.php (tắt theo mặc định, chỉ có hiệu lực trên bản cài Multisite).
  • Đã thêm widget Bảng điều khiển tùy chọn (tắt theo mặc định) hiển thị tóm tắt gọn “Lượt gửi bị chặn” với các kênh và lý do bị chặn hàng đầu.
  • Đã cập nhật mẫu dịch (.pot) và bản dịch tiếng Việt cho mọi chuỗi mới.

1.3 – 24 tháng 8, 2026

  • Đã sửa lỗi: lớp bảo vệ đăng nhập giờ cũng bao trùm wp_login_form() (dùng để đặt một form đăng nhập ở bất kỳ đâu trên frontend, ví dụ một widget hoặc mẫu theme). Trước đây chỉ form wp-login.php gốc được bảo vệ; một lượt gửi wp_login_form() ở frontend không mang trường honeypot nào và luôn bị từ chối với “Invalid login attempt.” khi lớp bảo vệ đăng nhập được bật.
  • Đã thêm ba filter dành cho lập trình viên — init_plugin_suite_void_shield_skip_login_verification, init_plugin_suite_void_shield_skip_register_verification, và init_plugin_suite_void_shield_skip_lostpassword_verification — để chủ động tắt mỗi lớp bảo vệ Form lõi WordPress cho một yêu cầu cụ thể bất kể công tắc trên trang cài đặt.

1.2 – 23 tháng 8, 2026

  • Đã thêm lớp bảo vệ honeypot tùy chọn cho các form đăng nhập, đăng ký, và quên mật khẩu mặc định của WordPress (mỗi cái đều tắt theo mặc định; bật riêng trong Form lõi WordPress).
  • Đã thêm tích hợp honeypot tùy chọn cho Contact Form 7, WPForms, và Gravity Forms (mỗi cái đều tắt theo mặc định; chỉ kích hoạt nếu plugin tương ứng đang hoạt động).
  • Đã thêm cài đặt tiền tố tên trường honeypot tùy chỉnh trong Bảo vệ nâng cao.
  • Đã thêm luân phiên bẫy CSS: kỹ thuật ẩn nội tuyến và thứ tự trường bẫy giờ được ngẫu nhiên hóa theo từng lượt dựng để làm việc học mẫu hình khó hơn cho các bot nhận biết CSS.
  • Đã thêm thống kê nhẹ, có thể tắt (bộ đếm lượt gửi bị chặn theo tổng/kênh/lý do) được lưu trong một tùy chọn duy nhất với autoload bị tắt rõ ràng, cùng một hành động đặt lại trên trang cài đặt.
  • Đã thêm phát hiện trình duyệt headless phía client (navigator.webdriver, cửa sổ kích thước 0) đặt bên trên kiểm tra token JS hiện có; không có lệnh gọi bên ngoài.
  • Đã tái cấu trúc công cụ honeypot thành một module nội bộ dùng chung, được tái sử dụng bởi form bình luận, các lớp bảo vệ form lõi WP, và cả ba tích hợp plugin form.
  • Đã sửa lỗi thông báo quản trị “Settings saved.” bị trùng lặp trên trang cài đặt (lõi WordPress đã tự động in ra thông báo này cho các trang trong menu Settings; plugin không còn in nó lần thứ hai).
  • Thay đổi: tham số thứ hai của filter init_plugin_suite_void_shield_honeypot_html giờ là chuỗi ngữ cảnh bảo vệ chung (ví dụ comment_123, login, cf7_4) thay vì chỉ là ID bài viết bình luận dạng số.

1.1 – 13 tháng 8, 2026

  • Đã thêm Lớp 5 tùy chọn: cài đặt “Chặn bình luận qua REST API” để từ chối các bình luận gửi trực tiếp qua endpoint REST wp/v2/comments, mà honeypot 4 lớp cổ điển không thể bao trùm vì nó không bao giờ thấy các yêu cầu đó.
  • Đã loại bỏ dự phòng script nội tuyến kiểu cũ trước 5.7; plugin giờ luôn dùng wp_get_inline_script_tag(), khớp với yêu cầu “Requires at least: 5.7” hiện có.

1.0 – 30 tháng 7, 2026

  • Phát hành lần đầu
  • Honeypot 4 lớp: trường động, bẫy ẩn bằng CSS, token thời gian đã ký, xác minh JS
  • Trang cài đặt: bật/tắt, áp dụng cho người dùng đã đăng nhập, thời gian gửi tối thiểu, độ trễ JS
  • API filter đầy đủ cho lập trình viên
  • Không dấu vết cơ sở dữ liệu
  • Giết mềm với HTTP 200 để đánh lừa bot