Problems register users ojs 3 . It did not pass the validation check used to prevent spam submissions

in the moment that user register , problem
It did not pass the validation check used to prevent spam submissions.

help please

image

This message indicates that the CAPTCHA response is not valid. Are you using ReCAPTCHA (as configured in config.inc.php)?

this is set up as is

Sorry, I can’t tell from that what setup you are using. Can you share the relevant setting of captha and captcha_on_register from config.inc.php? Do you see anything for a captcha on your registration page?

in the moment register next error
image

Hi @revistageon,

Could you please provide some additional details regarding your issue? Please provide the version you are using and the steps that lead to this error?

As well, it may be beneficially to take at this related post You did not pass the validation check used to prevent spam submissions - #11 by ojsfder

Kind Regards,
Patricia M.
Public Knowledge Project Intern

we do the suggested and still nothing

Hi @revistageon,

As previously mentioned, could you please provide some additional details regarding your issue? Please provide the version you are using and the steps that lead to this error?

Kind regards,
Patricia
PKP Intern

estoy utilizando la versiòn 3.1.1.

This suggests that Google is not returning a success message when verifying the captcha, but also is not providing a specific error.

If you are comfortable with PHP, you could add some debugging code here to see the actual response from Google:

Otherwise, you will want to double check your settings within the Google ReCaptcha Admin console. Is the key you are using valid for the domain you are using, or have you unset “Verify the origin of reCAPTCHA solutions”?

We’re having the same problem, if you don’t unset “Verify the origin of reCAPTCHA solutions” our institutional subscribers behind EZproxy cannot register.

It appears to be a major issue for people on shared hosting.

Our site has a SSL certificate for our.site.org and mail.our.site.org and it appears the EZProxy proxy causes the recpatcha to fail as it is returning mail.our.site.org

The recaptcha code in OJS should filter out subdomains before the recaptcha so that this problem does not happen.

This is an interesting scenario.

The validation of request origin for recaptcha is intended and important functionality, and it wouldn’t be technically feasible to whitelist/filter all possible proxy domains. (If you had a very small set of known proxies, you could add each one-by-one in Google, but this is an edge case.) Ideally, the resource being proxied does not know it is being proxied.

I think the real challenge here is that you are trying to use both Institutional subscription by IP and individual login by username here. Generally, Institutional subscription by IP is used when you want to grant anonymous access to an entire organization of users, and individual subscription (or registration) is used when you want to personalize that access. To have a user register over a proxied connection will break tools like Google ReCAPTCHA, because ReCAPTCHA depends on validating the access from the user perspective and from the server perspective simultaneously (and with a proxy, these perspectives intentionally diverge). Other CAPTCHA solutions would be possible.

Can you describe a bit more about your use case where proxied institutional subscriptions and personal user registrations are in use for the same constituents? I suspect that the proxy is being used generally for the institution, but select users also register for roles like editors and reviewers from the same institution. The solution might be technical (like removing / altering ReCAPTCHA) or procedural (asking some users not to use the proxy), or something else entirely, depending on your use-case.

Hi @ctgraham, I think you summed up the situation well. We have institutional subscribers that also need to login the author papers, and participate as reviewers. It is difficult to tell them to go home to upload papers or to review papers. And they cannot go around the proxy whilst they’re at work.

At the moment, everyone here is in stage 4 lock down, so this matter is likely to be on hold for another 4 weeks. But at that time, I’m likely to get issues again. Recently we enabled a setting in php.ini, something about fopen. we’re hoping that this will help when people return to work here.

I was going to ask their admin to test again in 4 weeks when they return to work. I’m hoping the outcome won’t be what occurred before - broken recpatcha behind the EZProxy.

thx, I appreciate the response.

The php.ini fopen configuration would be involved if your server was having trouble making an external request to google.com to validate the ReCAPTCHA submission, which is unlikely.

If you are comfortable making and maintaining a local modification to the code, you might want to disable ReCAPTCHA for the IP address(es) of the proxy server. If you already trust the users coming from that IP (range), you may not need ReCAPTCHA functionality for them.

I passed the same the same problem with OJS 3.3.0.6 but using the form from version 3.3.0.8 FormValidatorReCaptcha.inc.php and in the config.inc.php setting recaptcha_enforce_hostname = Off I can make a user registration, looking at the code of that form there changes, so I updated and the problem was resolved

1 Like