Support Thread for Google reCAPTCHA plugin

[David Allen]

I received a private message asking for help, so rather than replying to that I thought I'd post the question here so other can benefit as well

Hi David,

I was wondering if you could help me. I have installed your Google ReCaptcha mod and changed the look to 'Clean' and stuck it in a Div to centre it and it all works very well, what I am trying to do though is add this same code to 'Ask a Question' mod by Scott Wilson www.thatsoftwareguy.com

I can get it to look look exactly the same as on the other pages, however whether I enter the ReCaptcha code or not the form gets submitted. I don't get the message telling me I haven't filled this part of the form in. Any help you could give would be greatly appreciated.

Thank you for a great mod.

I think the questioner is using v1.39h.

If you look at the ReadMe instructions for pre 1.51 versions. In section 4A are the changes for /includes/modules/pages/contact_us/header_php.php
You need to apply those same changes to /includes/modules/pages/ask_a_question/header_php.php (the line numbers will be different, look around line 41)

Hope this helps
Regards

[Rjac]

Hi,

I'm actually using v1.5.1. this is a new install and not an upgrade from a previous version. The only other mods I have installed before this one were:

'Ashley Pink' template
'Ask a Question' Mod

Regards,

Robert.

I received a private message asking for help, so rather than replying to that I thought I'd post the question here so other can benefit as well


I think the questioner is using v1.39h.

If you look at the ReadMe instructions for pre 1.51 versions. In section 4A are the changes for /includes/modules/pages/contact_us/header_php.php
You need to apply those same changes to /includes/modules/pages/ask_a_question/header_php.php (the line numbers will be different, look around line 41)

Hope this helps
Regards

[David Allen]

Hi,

I'm actually using v1.5.1. this is a new install and not an upgrade from a previous version. The only other mods I have installed before this one were:

'Ashley Pink' template
'Ask a Question' Mod

Regards,

Robert.

Hi Robert
I had a look on the plugins and only found Ask a Question for the 1.39 version. So assumed you were using that - sorry.

Anyway, as the Ask a Question appears to be based on 1.39 code, the advice I gave above still stands. Use the 4A instructions on the ask a question header_php.php

Regards
David

[Michael Lu]

Hi David,

Sorry to bother you again.

I used the "Clean" template from Google and added below codes to file "create_account.php". I just put below codes on the top of the file(Before <?php)
<script type="text/javascript">
var RecaptchaOptions = {
theme: 'clean'
};
</script>

But when login or register, I got one blank web page. After refresh I could see content again but it is still at the login or register page. (Actually login or registed successfully becasue the "Logout" is shown on the top").

If I delete the codes above, everything is ok.

Do you konw what is the reason? Thanks very much!

Michael

[David Allen]

Hi David,

Sorry to bother you again.

I used the "Clean" template from Google and added below codes to file "create_account.php". I just put below codes on the top of the file(Before <?php)
<script type="text/javascript">
var RecaptchaOptions = {
theme: 'clean'
};
</script>

But when login or register, I got one blank web page. After refresh I could see content again but it is still at the login or register page. (Actually login or registed successfully becasue the "Logout" is shown on the top").

If I delete the codes above, everything is ok.

Do you konw what is the reason? Thanks very much!

Michael

Hi Michael
I think you have added the options to the wrong file. It should be added to /includes/templates/YOUR_TEMPLATE/templates/tpl_modules_create_account.php (and the equivalent files for write a review and contact us)

Regards

[Michael Lu]

Hi Michael
I think you have added the options to the wrong file. It should be added to /includes/templates/YOUR_TEMPLATE/templates/tpl_modules_create_account.php (and the equivalent files for write a review and contact us)

Regards

Hi David,

You are right. I found the answer still in your previous post. Thanks again for your kindly help. Cheers!

Michael

[kjetilhansen]

Hello :)

What am I doing wrong when I've installed the plugin, it seems to be working, but if I go to contact us and fill out the form and don't fill out the captcha it still sends the form?

-Kjetil Hansen

[David Allen]

Hello :)

What am I doing wrong when I've installed the plugin, it seems to be working, but if I go to contact us and fill out the form and don't fill out the captcha it still sends the form?

-Kjetil Hansen

Hi Kjetil
Can I ask which version of zen cart you are using?
Regards

[mc12345678]

Only recently discovered a few things and made some changes to the code that was provided for Google ReCaptcha Version 1.1. Running ZenCart 1.5, with multiple add-ins installed. This or a similar add-in was identified early on as being necessary as a result of spam we began receiving last year. This has reduced that significantly.

So couple of issues, one that I didn't see anyone discuss/question, the other that I saw related to an offered solution.

1. The first is related to SSL: Unfortunately our organization has not acquired a SSL address that is the exact same as our NONSSL address, ie we used a shared certificate. Fortunately though the SSL address does not require any appended folder or login name to access the site, so while we may have Server.extension, our shared address is ServerExtension.Host.Extension2.

So it appears that when customers would try to create an account without previously having one created via an online purchase, our google captcha wouldn't work because we had obtained a private key from google that was not global and we had not obtained two unique keys to handle SSL and NONSSL. So... For those that have a shared certificate, we are able to NOT have a global google key, but still use recaptcha on both secure and non-secure webpages. Surrounding the following code in /storefolder/includes/functions/extra_functions/recaptchalib.php modified the below code:

$publickey = "YOUR_PUBLIC_KEY";
$privatekey = "YOUR_PRIVATE_KEY";

if ($request_type == 'SSL') {
$publickey = "YOUR_SHAREDHOST_PUBLIC_KEY";  
$privatekey = "YOUR_SHAREDHOST_PRIVATE_KEY";
} elseif ($request_type == 'NONSSL') {
$publickey = "YOUR_HOSTED_PUBLIC_KEY"; 
$privatekey = "YOUR_HOSTED_PRIVATE_KEY";
}

Both of those sets of keys are to be obtained from google as described in the file.

Probably could/should use a check against values in the configuration.php file to further simplify the above code; however, I hadn't thought about the benefit yet... Probably could have variables to enter all of the keys, informing the user to only enter the keys that they believe necessary and not to worry about the keys they do not need to modify, then later in the code, compare the server setup to identify if the additional keys would need to be used setting the individual keys "YOUR_SHAREDHOST_PUBLIC_KEY", etc... as required to continue moving forward. Otherwise, a hosted service that has a certificate for both the http: and https: version of the web address would have to enter the set of keys twice in the above code, or remove the additional code that performs the tests. For upgrade purposes I would think that updating a potential two lines of code to handle 2 situations would be better than updating 4 lines of code to handle the same 2 situations. At any rate...

Using the above code change, we are able to maintain the trusted security that our keys will only be used on our server/host, and not able to be passed around to be used anywhere for any reason, etc... (Security aspect.)

2. The other fix that I recommend, assuming that I follow the logic of other code in ZenCart, is that when calling recaptcha_get_html, instead of hard coding true into the command, to use what seems to be the more programmer friendly $request_type variable for comparison. It seems to me that ZenCart will assign $request_type = 'SSL' for pages loaded https:, and $request_type = 'NONSSL' for other pages. I tried to look around other areas that included reference to $request_type and it did seem like there were some checks with another variable to see if the other variable indicated more of a NONSSL condition; however, it seemed that those tests were more for addressing the admin panel than for the rest of the store and/or I didn't understand the need for the additional comparisons. So wherever the recaptcha_get_html was called, I used:

<?php echo recaptcha_get_html($publickey, $resp->error, $request_type == 'SSL'); ?>

This way, there is a consistent approach to implementation, and if the $request_type is consistently/accurately set, then the recaptcha will be properly presented without 'src=' error(s) causing the visitor to see that there is mixed content being presented.

[David Allen]

Only recently discovered a few things and made some changes to the code that was provided for Google ReCaptcha Version 1.1. Running ZenCart 1.5, with multiple add-ins installed. This or a similar add-in was identified early on as being necessary as a result of spam we began receiving last year. This has reduced that significantly.

So couple of issues, one that I didn't see anyone discuss/question, the other that I saw related to an offered solution.

1. The first is related to SSL: Unfortunately our organization has not acquired a SSL address that is the exact same as our NONSSL address, ie we used a shared certificate. Fortunately though the SSL address does not require any appended folder or login name to access the site, so while we may have Server.extension, our shared address is ServerExtension.Host.Extension2.

So it appears that when customers would try to create an account without previously having one created via an online purchase, our google captcha wouldn't work because we had obtained a private key from google that was not global and we had not obtained two unique keys to handle SSL and NONSSL. So... For those that have a shared certificate, we are able to NOT have a global google key, but still use recaptcha on both secure and non-secure webpages. Surrounding the following code in /storefolder/includes/functions/extra_functions/recaptchalib.php modified the below code:

$publickey = "YOUR_PUBLIC_KEY";
$privatekey = "YOUR_PRIVATE_KEY";

if ($request_type == 'SSL') {
$publickey = "YOUR_SHAREDHOST_PUBLIC_KEY";  
$privatekey = "YOUR_SHAREDHOST_PRIVATE_KEY";
} elseif ($request_type == 'NONSSL') {
$publickey = "YOUR_HOSTED_PUBLIC_KEY"; 
$privatekey = "YOUR_HOSTED_PRIVATE_KEY";
}

Both of those sets of keys are to be obtained from google as described in the file.

Probably could/should use a check against values in the configuration.php file to further simplify the above code; however, I hadn't thought about the benefit yet... Probably could have variables to enter all of the keys, informing the user to only enter the keys that they believe necessary and not to worry about the keys they do not need to modify, then later in the code, compare the server setup to identify if the additional keys would need to be used setting the individual keys "YOUR_SHAREDHOST_PUBLIC_KEY", etc... as required to continue moving forward. Otherwise, a hosted service that has a certificate for both the http: and https: version of the web address would have to enter the set of keys twice in the above code, or remove the additional code that performs the tests. For upgrade purposes I would think that updating a potential two lines of code to handle 2 situations would be better than updating 4 lines of code to handle the same 2 situations. At any rate...

Using the above code change, we are able to maintain the trusted security that our keys will only be used on our server/host, and not able to be passed around to be used anywhere for any reason, etc... (Security aspect.)

2. The other fix that I recommend, assuming that I follow the logic of other code in ZenCart, is that when calling recaptcha_get_html, instead of hard coding true into the command, to use what seems to be the more programmer friendly $request_type variable for comparison. It seems to me that ZenCart will assign $request_type = 'SSL' for pages loaded https:, and $request_type = 'NONSSL' for other pages. I tried to look around other areas that included reference to $request_type and it did seem like there were some checks with another variable to see if the other variable indicated more of a NONSSL condition; however, it seemed that those tests were more for addressing the admin panel than for the rest of the store and/or I didn't understand the need for the additional comparisons. So wherever the recaptcha_get_html was called, I used:

<?php echo recaptcha_get_html($publickey, $resp->error, $request_type == 'SSL'); ?>

This way, there is a consistent approach to implementation, and if the $request_type is consistently/accurately set, then the recaptcha will be properly presented without 'src=' error(s) causing the visitor to see that there is mixed content being presented.

Hi mc
Looks like you have found a good solution to the problem of having different SSL and nonSSL domain names and hence different Google keys. For point 2 - the exact code that you suggest has already been implemented in the 1.51 version (great minds think alike :) )
Regards
David