Open timiwahalahti opened 5 years ago
@k1sul1 could you check this and merge if looks ok, thanks!
honeypot
filters.function wplf_is_honeypot_enabled () {
// more friendly and don't repeat yourself
return apply_filters( 'wplf_honeypot', true );
}
function wplf_get_honeypot_field_name () {
return apply_filters( 'wplf_honeypot_field_name', 'send_hugs_to_developers' );
}
Maybe a "hash" is better than a name... e3251075554389fe91d17a794861d47b
instead of send_hugs_to_developers
. Just personal preference.
This honeypot should be added via javascript. Most bots don't execute javascript. If the honeypot is missing, this is a bot. So mark as spam. Or if the honeypot is not missing but is filled, it is a bot too.
I like the idea of banning very fast requisitions. Example: mark as spam any form request sent in less than 10 seconds.
I prefer functions to return the honeypot filters.
@luizbills can you explain why? Hooks are the default way WP and also WP Libre Form functionality works. I don't really see any advantages with using wrapper functions for filters.
Maybe a "hash" is better than a name instead of
send_hugs_to_developers
. Just personal preference.
Yeah, there are many schools of thoughts with this one. Personally, I prefer some obsecure but obiviosuly fake name and that seems to be the industry standard after doing some research. The field name can be changed with filter, to fulfill everyone's personal preferences :)
This honeypot should be added via javascript. Most bots don't execute javascript.
I really don't like the javascript way of doing this simple thing. Also WP Libre Form is going to have no-js fallback (#64) so doing honeypot with js, would cause a extra work with no-js fallback feature. Also future is here and we have headless chrome here, which executes javascript and can be used to send spam. Many spammers might not use that now, but it's in the future.
I like the idea of banning very fast requisitions. Example: mark as spam any form request sent in less than 10 seconds.
This can be good addition to JS side! But as said earlier, I wouldn't like to count on JS only when making spam prevention since we are going to have a no-js fallback.
Adds a simple honeypot to detect and prevent spam. #54 related.
Honeypot we check against is simple field
<input type="checkbox" name="send_hugs_to_developers" value="1" style="display:none !important" tabindex="-1" autocomplete="off">
.This PR also introduces
spam
andspam_save
variables in submission$return
because we need a way to mark the spam and set if spam should be saved to the database. Way to mark spam can be used easily to extend spambot checks to use Akismet if developers want to do that. And spam saving is a good idea, because of possible false positives. Submissions marked as spam, are saved as trash so WP cleans up those after 30 days.All of these features can be turned off via hooks. For example, if a site gets loads of spammy submissions, it's wise not to save those.