Snaptcha 3 adds more control over which form submissions and users to validate, as well as a fail-safe method for dealing with false negatives (submissions that are incorrectly believed to be spam).
Since Snaptcha is invisible and extremely effective at blocking spam form submissions, showing off what it does has always been a challenge. The only way to really appreciate it is to install it and see how automated spam submissions drop to zero, especially for public forms on your Craft site.
One bonus of Snaptcha 3 is that we can see exactly what the user experiences when a submission is incorrectly marked as spam. Below is a side-by-side comparison with the user-experience of “invisible” Recaptcha 3.
How Snaptcha works #
We believe that plugins should not be treated like black boxes. How Snaptcha works is no secret and there’s no magic behind the scenes. Snaptcha uses several factors to determine whether a POSTed form was submitted by a human or a spambot.
The second is that the “minimum submit time” (an adjustable number of seconds) must have passed between the time that the Snaptcha field was generated and the form was submitted.
The third is that the field must still be valid by not having already been used (if one-time key is enabled) and the “expiry time” (an adjustable number of minutes) not having passed.
Additionally, it is possible to disable Snaptcha validation for logged-in users (only recommended if public registration is not enabled), for specific controller actions and for specific IP addresses. All of these are available in the plugin settings.
What Snaptcha can(not) do #
From the explanation above, you may be wondering how Snaptcha protects submissions from human spammers. It is important to realise that Snaptcha is an automated spam protection tool that can only block out automated spam (from spambots). No automated tool can block out 100% of spam without relying on manual moderation (human intervention), and Snaptcha is no different.
Breaking Changes #
Snaptcha 3 includes one change which may be considered a “breaking change” The “Excluded URI Patterns” setting has been removed, since we determined that this setting could be abused in some circumstances. Use the new “Exclude Controller Actions” setting instead, or if that doesn’t suffice then you can use the EVENT_BEFORE_VALIDATE_FIELD event from your own plugin/module to bypass validation by setting
true on the event.
View the changelog or read the documentation to discover more.