How does this plugin validates recaptcha's response?

[stenvdb]

Correct me if I'm wrong, but this plugin depends solely on the frontend tag which does the call to Google and sends back the response. Shouldn't there be a validation in the backend that checks the response by default?

Again, if I'm correct when the user (or a spam bot) visits the site with JavaScript disabled, the form will always submit and all potential spam gets through.

[clarknelson]

Correct, the frontend tag talks to google to get a key, and then the key is sent to the craft server where it is sent again.

I can confirm that the form will submit if javascript is disabled, but how do you propose we counter this? I feel like there are trade offs with either approach, where locking everyone out without javascript could also cause problems.

If you have a proposed approach I would love to hear it!

[stenvdb]

You could move the backend validation check from the controller action to a separate service like the older plugin did (the recaptcha v2 plugin for craft https://github.com/matt-west/craft-recaptcha#verify-the-recaptcha). Then people could implement their own backend validation check and use your service. I'm currently doing something similar with a custom module. But instead of using a plugin's service I'm just doing a curl call to Google reCaptcha's validation service.

But I would at the very least include something in your docs like the v2 plugin did (see link above) so people are aware that this plugin will no validate spam when JavaScript is disabled.

[arifje]

Any update on this? We need the server side auth too, because spam bots are triggering forms directly, skipping javascript :-[

[cliveportman]

Seconding this. This needs backend validation because at the moment it's simply not reliable.

[clarknelson]

Sorry for the radio silence. I agree this would be a good change, but it would require a lot of rewriting code. Once I have the time to address this I will do so.

[clarknelson]

I have been mulling this issue, please let me know your thoughts.

1. There should be some validation on the backed. Yes there is a front-end script, but it sends a request to the plugin backend, which then sends it to Google. This isn't an entirely front-end script.

2. How would this plugin work if javascript was disabled? I believe recaptcha requires a key from the front end and a key from the back end. The only way to get a front-end key is to send an AJAX request to Google.

Wouldn't my plugin be simplier than the matt-west plugin since you do not need to write any PHP? The PHP code is written by me and calls functions on the front-end.

Let me know if this answers the question, of if there is something I am overlooking.

[stenvdb]

Hi @clarknelson , for what it's worth I don't really rely on this plugin anymore. I use a site module that hooks into the Guest Entries EVENT_BEFORE_SAVE_ENTRY event, do a curl call myself to Google's reCaptcha service and take it from there..

If you want backend validation in this plugin for other users, I suppose you could do this via a plugin setting: "validate guest entries / contact form submissions". If set to true, you can hook into the guest entries / contact form event in your plugin, do the validation, and based on the response block the entry from saving, or continue.

This is basicly what rias does in his plugin, see: https://github.com/riasvdv/craft-contact-form-extensions/blob/d489d2ec97b39c6949061307dce87dc7a18a05fa/src/ContactFormExtensions.php#L116

[clarknelson]

Thanks for letting me know, I would still like to improve the plugin for myself and others.

I think I understand a bit more about where you expect this plugin to fit into the backend. I view this service as more of a "okay this guy is legit" instead of "okay you can save / send this entry".

I believe a method in PHP like you suggested would be of benefit to users. This way developers can use the method to validate actions. Won't it still need to make a request on the front-end?

Maybe we should include the script at the bottom of each page, which makes the request for the key and stores it on the server. Then we can make the backend request with the front-end key whenever we want? Maybe some actions like contact form submissions and guest entry saving is validated by default (if the plugin is activated).

Regardless these are a lot of changes to make, but I enjoy talking through them with people here so I can better understand how to improve the plugin.

[j-greig]

Just wondering if there are any further thoughts on this?

We enabled Recaptcha on a "Request account" form last night and immediately got a spambot submission.

[sandervandenijssel]

I have a question. My CAPTCHA sets al scores to 0.9 making them all valid. As I was reading in the Google documentation:

Note: reCAPTCHA tokens expire after two minutes. If you're protecting an action with reCAPTCHA, make sure to call execute when the user takes the action rather than on page load.

In your documentation i saw this:

window.recaptcha_callback = function(response){ ... }
window.recaptcha_success = function(){ ... } 
window.recaptcha_failure = function(){ ... }_

It seems to me global vars are set by page load. I want to have the recaptcha state onSubmit leave Recaptcha more time to test my user. Say:

$("#button").on("click", function () {
   window.recaptcha_success = function(){ //submit here } 
});  

Question 1 : does the window.recaptcha_callback only gets called on page load? (So I can't call EXECUTE again)
Question 2 : Is the above example better / possible?

[clarknelson]

thanks for looking into this, there may be a problem with our implementation.

I will need to do some more research regarding the best way to fix. Sorry if the plugin is not working as intended.