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:
Code:
$publickey = "YOUR_PUBLIC_KEY";
$privatekey = "YOUR_PRIVATE_KEY";
Code:
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:
Code:
<?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.
