You did not pass the validation check used to prevent spam submissions

This message indicates that either your php.ini changes are not effective (did you need to restart apache?) or they are overriden by something else which is turning off allow_url_fopen.

No. I didn`t restart apache. Just manage API and the error appear. On other websites work fine. In both files allow_url_fopen are ON. What I can do to activate allow_url_fopen?

Are the other websites running under the same apache instance? If you are modifying php.ini with an apache instance which is using mod_php, the apache instance must be restarted for the php.ini change to take effect. If you are using a webserver with php configuration via .htaccess or similar (like CPanel), PHP configuration changes should be effective immediately. Do you have a system administrator or hosting provide who can give you in your particular setup?

I will check with provider and will inform you. Thanks.

We just checked with our provider. They checked all and there are no errors showing at their end. allow_url_fopen are ON in both files.

_php.ini has:
;allow_url_fopen = On
;allow_url_include = Off
;asp_tags = Off
;display_errors = Off
;enable_dl = Off
;file_uploads = On
;max_execution_time = 60
;max_input_time = 60
;max_input_vars = 1000
;memory_limit = 100M
;session.save_path = “”
;upload_max_filesize = 100M

In config.inc.php has:
;;;;;;;;;;;;;;;;;;;;
; Captcha Settings ;
;;;;;;;;;;;;;;;;;;;;

[captcha]

; Whether or not to enable ReCaptcha
recaptcha = on

; Public key for reCaptcha (see http://www.google.com/recaptcha)
recaptcha_public_key = API KEY - removed now

; Private key for reCaptcha (see http://www.google.com/recaptcha)
recaptcha_private_key = API KEY- removed now

; Whether or not to use Captcha on user registration
captcha_on_register = on

; Validate the hostname in the ReCaptcha response
recaptcha_enforce_hostname = off

;;;;;;;;;;;;;;;;;;
; Proxy Settings ;
;;;;;;;;;;;;;;;;;;

[proxy]

; Note that allow_url_fopen must be set to Off before these proxy settings
; will take effect.

; The HTTP proxy configuration to use
; http_host = localhost
; http_port = 80
; proxy_username = username
; proxy_password = password

What you suggest to do next?

The statement in _php.ini appears to me to be commented out with the ; .

Are you confident that syntax is correct? I would have expected to see:

allow_url_fopen = On

Now, php.ini changed in:
allow_url_fopen = On
;allow_url_include = Off
;asp_tags = Off
;display_errors = Off
;enable_dl = Off
;file_uploads = On
;max_execution_time = 60
;max_input_time = 60
;max_input_vars = 1000
;memory_limit = 100M
;session.save_path = “”
;upload_max_filesize = 100M

Still doesn`t work and in error.log received:

[18-Aug-2020 14:18:15 UTC] PHP Warning: file_get_contents(): https:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /data04/c6410587/public_html/murmurations/ojs/lib/pkp/classes/form/validation/FormValidatorReCaptcha.inc.php on line 89
[18-Aug-2020 14:18:15 UTC] PHP Warning: file_get_contents(https://www.google.com/recaptcha/api/siteverify): failed to open stream: no suitable wrapper could be found in /data04/c6410587/public_html/murmurations/ojs/lib/pkp/classes/form/validation/FormValidatorReCaptcha.inc.php on line 89

It still appears that allow_url_fopen is disabled. You can confirm if this is true by logging in as the Site Administrator, then navigating to Administration → System Information → Extended PHP Information.

Under the “Core” section, “allow_url_fopen” will be listed with a “Local Value” and with a “Master Value”. Master Value is the first directive which PHP’s configuration registered. The Local Value is the effective value as presented to OJS.

Is this Local Value Off or On?

Interesting. There is obviously OFF.

allow url fopen

How to activate it to be ON?

I think you will need to reach back out to your hosting provider. Describe that you are trying to turn on this PHP configuration option, and what specifically you have tried (editing which files, where). They should be able to tell you what to do.

Dear @ctgraham ,

as always, you were right. When providers solve the problems that Under the “Core” section, “allow_url_fopen” is ON and we see in Administration → System Information → Extended PHP Information that it is ON everything start working.
Thank you for this recommendation.

We’re on OJS 3.3.0.6 and facing the same issue. Proxy support is enabled and I believe, the all new proxy support does not cover reCaptcha things yet? AT least our recpatcha issues started since the latest big upgrade to the latest OJS version. url_fopen is not an option and never was because we are sitting behind a proxy. That never changed. But OJS recpatcha has stopped working now.

I’m not a robot: Pass but then the error message appears.

Am I right @ctgraham / @asmecher ?

1 Like

What was your previous version of OJS?

Proxy support for ReCAPTCHA in OJS 3.3.0-6 looks to be the same as implemented four years ago:

There was a recent change in 3.3 where the URL was changed from google.com to recaptcha.net:

Is it possible that your proxy needs to whitelist this new domain?

Yes, the proxy things there didnt change - but the OJS one:

;;;;;;;;;;;;;;;;;;
; Proxy Settings ;
;;;;;;;;;;;;;;;;;;

[proxy]

; The HTTP proxy configuration to use
http_proxy = "http://host:port"
https_proxy = "http://host:port"

is NEW (adapted to my needs - this is the new template: ojs/config.TEMPLATE.inc.php at 8b10104d464322e48b5dd5466a7d6f0fd3187b49 · pkp/ojs · GitHub) and:

;;;;;;;;;;;;;;;;;;
; Proxy Settings ;
;;;;;;;;;;;;;;;;;;

[proxy]

; Note that allow_url_fopen must be set to Off before these proxy settings
; will take effect.

; The HTTP proxy configuration to use
; http_host = localhost
; http_port = 80
; proxy_username = username
; proxy_password = password

was then.

Could this cause issues now? EDIT: I would say yes - because the variable name changed from http_host to http_proxy. So, for your recpatcha script, no proxy is now set.

Would be even nicer, if the recpatcha would use the generic HTTP-things (curl).

You are correct. The name of the configuration variable changed in 3.3, but ReCAPTCHA isn’t updated to use the new setting before the (unreleased) 3.4.

Adding the old name (http_host) back into your config.inc.php (in addition to the new names) should continue support for ReCAPTCHA in 3.3.0-6, pending the actual fix.

1 Like

See this issue filed as a result of the above post: ReCAPTCHA proxy is misconfigured · Issue #7174 · pkp/pkp-lib · GitHub