reCaptcha
reCaptcha copied to clipboard
reCaptcha show up twice on One Page Checkout
Hi,
for some reason the reCapture shows up twice on the "one page checkout".

The first has the id "captcha-925-input-box-guest_checkout" The second has the id "captcha-883-input-box-register_during_checkout"
Could you please help me to solve the problem.
Best Regards Peter
Hi,
Have you tried to see if issue persists on a plain base RWD theme? If this is an issue on a production site, to overcome this, disable either checkout guest recapctha or checkout register recapctha, which will eliminate one of the duplication.
Unfortunately I don't have the time right now to debug this for you.
Closed due to inactivity
@ProxiBlue , I'm facing the same issue and debugged that a bit.
Usually one of the captcha forms should be removed in js/mage/captcha.js.
But there Magento is looking for an element with the id captcha-input-box-guest_checkout, resp. captcha-input-box-register_during_checkout
Unfortunately you change the class ids in \ProxiBlue_ReCaptcha_Model_Recaptcha::getElementId, so that we have ids like captcha-688-input-box-guest_checkout.
This way always both elements are shown.
I now disabled the register_during_checkout captcha. Now always only one is shown but this way also only the guest_checkout is actually validated.
For the register checkout you can continue even without clicking the captcha.
It's the same the other way around.
Tested it also with default theme and can confirm that it happens there as well. So it's not related to the custom theme. Would be great if you could take a look at that issue, it should be reproducible in general. Feel free to contact me if you have further questions.
Hello,
I will have a look int this, things must have chanegd somewhere, breaking the integration. What version of m1 you on?
@ProxiBlue , thanks for the fast reaction. We're using the latest M1, so 1.9.4.5 with all current MageOne Patches included (which should not matter in my eyes). Please let me know, if you can not reproduce the issue on your side.
Ok, I will give it a test on 1.9.4.5. I no longer actively use this module, so likely an update to checkout has broken things.
Hello, I am currently hospitalised with a serious trauma wound, and will get to this when I can.
I am unsure when that will be, likely in about 2-3 weeks
I have been discharged, for further care from @home via daily nurse visists :+1:
SO I can look into this now, and I can 100% reproduce

on a clean openmage install
Hello, I have released v 2.3.7, which I believe fixes this issue.
Please have a test and let me know.
@ProxiBlue , just tested it. Looks fine and seems to work. Thanks a lot for the fast fix.
@ProxiBlue , we just found an issue with your new release. Until now, we only tested using the visible ReCaptcha and the default Google test keys. So we could make sure, that the ReCaptcha is actually used and fails every time. Now we switched to invisible and used our real keys. Doing this, we found out, that the validation fails every time when you try to enter your billing address in the checkout as a guest. All other captchas seem to work properly and you don't get the issue, when you are logged in.
Please be so kind and try to reproduce and test on your side. Thanks and best regards.
Hello, I will look into this, thanks for reporting.
Hello, is your failure after Billing submit an actual reCaptcha failure message, or are you flicked back to cart?
I am not able to reproduce the issue, works every time
https://drive.google.com/file/d/1MrJ_Rea161WHMWo3dHJn8te8754tJ99A/view
In admin, enable the debug log

Then after your fail, check the debug log located at
My example log is as such:
2021-02-02T12:52:07+00:00 DEBUG (7): Form ID: recapctha_checkout=>Array
(
[billing] => Array
(
[address_id] => 29
[firstname] => Lucas
[middlename] =>
[lastname] => van Staden
[company] =>
[email] => [email protected]
[street] => Array
(
[0] => 1 Main Street
[1] =>
)
[city] => Ney York
[region_id] => 1
[region] =>
[postcode] => 12345
[country_id] => US
[telephone] => 12445
[fax] =>
[customer_password] =>
[confirm_password] =>
[save_in_address_book] => 1
[use_for_shipping] => 1
)
[g-recaptcha-response] => 03AGdBq25z2wUlxTOmY5gzENOdqEK1nUQloAfOlK_HX7qolN4E0QaoLtkS060Gu8WF1z78COi9yN9IEsKhfHSjtTuvo5WztDUXrlJ2T0m8-asoyZDHITz_lSMotRRZfKH8NCy-bCJewzHo3XnpbsJ7bLfgWBACbrIEEBI_0miMBeimKwLR1PXM4oFAp-RIbw36_6bOS9Rjlm-bFTXjpS2bcbq5q2IYIuWoumNsRJF4vbX7d7SIjk1l5htuMwsHhnSOTC0NcODWr-AKYTOvCymX5xOhvdbOJJA4RuikMcXIgC38Mdl-QRxVTU8PIlQ8thEAhxrfJymrTzLSVovwzbWt9QtijImXwIjw2DoH6maGhN30Q3QBt-tGFj7uts0BUKVLC2_wckjW8QD1Oki8a67Ej13xy0Sgpn0-iQMAeZF_Yiepwbd8l3afaBWTu-TOvN7N36fEmN5pSUYuR4ILO2o5YQ4roE6DDJ-_bw
[form_key] => VxCATwjjLj6whTcM
)
2021-02-02T12:52:07+00:00 DEBUG (7): Form ID: recapctha_checkout=>sending to siteverify params of Array
(
[secret] => xxxxxxxxxxxxxxxxxxxx
[response] => 03AGdBq25z2wUlxTOmY5gzENOdqEK1nUQloAfOlK_HX7qolN4E0QaoLtkS060Gu8WF1z78COi9yN9IEsKhfHSjtTuvo5WztDUXrlJ2T0m8-asoyZDHITz_lSMotRRZfKH8NCy-bCJewzHo3XnpbsJ7bLfgWBACbrIEEBI_0miMBeimKwLR1PXM4oFAp-RIbw36_6bOS9Rjlm-bFTXjpS2bcbq5q2IYIuWoumNsRJF4vbX7d7SIjk1l5htuMwsHhnSOTC0NcODWr-AKYTOvCymX5xOhvdbOJJA4RuikMcXIgC38Mdl-QRxVTU8PIlQ8thEAhxrfJymrTzLSVovwzbWt9QtijImXwIjw2DoH6maGhN30Q3QBt-tGFj7uts0BUKVLC2_wckjW8QD1Oki8a67Ej13xy0Sgpn0-iQMAeZF_Yiepwbd8l3afaBWTu-TOvN7N36fEmN5pSUYuR4ILO2o5YQ4roE6DDJ-_bw
)
2021-02-02T12:52:09+00:00 DEBUG (7): Form ID: recapctha_checkout=>result is : {
"success": true,
"challenge_ts": "2021-02-02T12:51:27Z",
"hostname": "openmage.uptactics.test"
}
@ProxiBlue , thanks a lot for your fast reply.
Activated the logging and found out, that the g-recaptcha-response is missing as soon as I choose the position Bottom Right or Bottom Left for the Recpatcha.
When I display it inline, everything is fine and the response is taken correctly.
Can you give me an advice how to fix that?
Sounds like a javascript issue. When the code submits the response is coppied into the post request. Sounds like that is missing.
Are you hiding the recaptcha elements with css?
On Wed, 3 Feb 2021, 00:02 Ole Schäfer, [email protected] wrote:
@ProxiBlue https://github.com/ProxiBlue , thanks a lot for your fast reply. Activated the logging and found out, that the g-recaptcha-response is missing as soon as I choose the position Bottom Right or Bottom Left for the Recpatcha. When I display it inline, everything is fine and the response is taken correctly. Can you give me an advice how to fix that?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProxiBlue/reCaptcha/issues/43#issuecomment-771741667, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGDJVAGF4EGQ4WDIKNI5GDS5AO2PANCNFSM4KC5WLAA .
Any javascript errors in browser console?
On Wed, 3 Feb 2021, 00:02 Ole Schäfer, [email protected] wrote:
@ProxiBlue https://github.com/ProxiBlue , thanks a lot for your fast reply. Activated the logging and found out, that the g-recaptcha-response is missing as soon as I choose the position Bottom Right or Bottom Left for the Recpatcha. When I display it inline, everything is fine and the response is taken correctly. Can you give me an advice how to fix that?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProxiBlue/reCaptcha/issues/43#issuecomment-771741667, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGDJVAGF4EGQ4WDIKNI5GDS5AO2PANCNFSM4KC5WLAA .
@ProxiBlue , we found the issue. We generally include the newsletter subscription with the corresponding ReCaptcha, which we added manually, in the footer. Unfortunately this one is cached as long as the customer is on other pages than the checkout and so the check in your code, if we are in the checkout, fails for this ReCaptcha. And this way the validation is not triggered correctly. So actually not related to your extension, but to our customizations. Thanks nevertheless for your fast reply.
Glad you got it solved.
On Fri, 5 Feb 2021, 05:11 Ole Schäfer, [email protected] wrote:
@ProxiBlue https://github.com/ProxiBlue , we found the issue. We generally include the newsletter subscription with the corresponding ReCaptcha, which we added manually, in the footer. Unfortunately this one is cached as long as the customer is on other pages than the checkout and so the check in your code, if we are in the checkout, fails for this ReCaptcha. And this way the validation is not triggered correctly. So actually not related to your extension, but to our customizations. Thanks nevertheless for your fast reply.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProxiBlue/reCaptcha/issues/43#issuecomment-773606399, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGDJVH3OXUSMNA2UAIO22DS5MER3ANCNFSM4KC5WLAA .
@ProxiBlue , I fear we now have another issue, which might be related to the fix for this ticket.
Are you sure, that the register_during_checkout captcha works with your fix?
As we now solved our cache issue, we tested both ways again and as the guest_checkout works fine, the other always fails.
We debugged a bit and found the following:
- In
app/design/frontend/base/default/template/captcha/recaptcha.phtmlyou look for.captcha-image-box-register_during_checkout. This does not exist in our case. - According to
app/design/frontend/base/default/layout/captcha.xmlthis should be included incheckout.onepage.billinginform.additional.info. - I debugged into that and found out that only the
guest_checkoutcaptcha is rendered. The other is empty, as\Mage_Captcha_Block_Captcha_Zend::_toHtmlchecks if it is required and this returns false. - Following this, I saw in
\ProxiBlue_ReCaptcha_Model_Recaptcha::isRequiredthat the form id is stillregister_during_checkoutwhich leads me to\ProxiBlue_ReCaptcha_Model_Recaptcha::_getTargetForms - There you unset both form IDs from the
$formsarray, but only setrecapctha_checkoutfor one. In our case this isguest_checkout. - This is why the
register_during_checkoutis not required and not rendered as html. - But as far as I understood
js/mage/captcha.jswe need both, but just hide one
Please correct me, if I did not understand the whole process, but I would say we need both captchas in the code, which is currently not the case.
Hello, checking if I can reproduce
You should not need both, as the code will find the first one (as what ho google code does) and copy the response. Googles own code don't ever expect more than one recapctha element, so they just find the first one, and use it.
They never expect multiple.
However, I can agree that the register now fails (oops)
I am looking into it.
I am 100% sure I tested that prior, but maybe a clean cache/slate changed the state of something
Ok, so the issue is that I now transpose the separated form ids from the previous MULTIPLE captcha entities to one, with one form id. Core code is still looking for the original form ids
@norgeindian
Have a go with https://github.com/ProxiBlue/reCaptcha/releases/tag/2.3.8
@ProxiBlue , thanks a lot for your fast work here, that seems to work
NP
A lot of stores use this module. If they composer update with a blanket verion update a lot of stores will break.
Swift resolution prevent a lot of angry people ;)
On Sat, 6 Feb 2021, 16:59 Ole Schäfer, [email protected] wrote:
@ProxiBlue https://github.com/ProxiBlue , thanks a lot for your fast work here, that seems to work
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProxiBlue/reCaptcha/issues/43#issuecomment-774428596, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGDJVCD6YD2HOU7NIL3CBDS5UAHLANCNFSM4KC5WLAA .
@norgeindian
Please update to 2.3.9. I found a bug in 2.3.8 which will block checkout if reCapctha is not actually selected in admin to BE in checkout (in use on invisible) The adjusted validation in this bug will continue to validate response, but will fail as is not actually enabled IN checkout.
@ProxiBlue , shortly tested your new version. But I think your fix does not work.
I have activated all ReCaptcha Forms in the Backend Config and everything worked in 2.3.8.
When I now use your new version, the Captcha is not validated at all in the checkout.
Please take a look at \ProxiBlue_ReCaptcha_Model_Recaptcha::_getTargetForms
There you unset register_during_checkout and guest_checkout from $forms[].
In 2.3.9 now you check exactly for these entries in \ProxiBlue_ReCaptcha_Model_Recaptcha::isRequired.
I would say this deactivates the check in general, if I see that correctly. No matter what you activate in the backend.
Crap. I only tested not selected. Will confirm. Thanks for the feedback.
On Mon, 1 Mar 2021, 15:26 Ole Schäfer, [email protected] wrote:
@ProxiBlue https://github.com/ProxiBlue , shortly tested your new version. But I think your fix does not work. I have activated all ReCaptcha Forms in the Backend Config and everything worked in 2.3.8. When I now use your new version, the Captcha is not validated at all in the checkout. Please take a look at \ProxiBlue_ReCaptcha_Model_Recaptcha::_getTargetForms There you unset register_during_checkout and guest_checkout from $forms[]. In 2.3.9 now you check exactly for these entries in \ProxiBlue_ReCaptcha_Model_Recaptcha::isRequired. I would say this deactivates the check in general, if I see that correctly. No matter what you activate in the backend.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ProxiBlue/reCaptcha/issues/43#issuecomment-787719322, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGDJVGFUVC426FLBXMPCS3TBM6R5ANCNFSM4KC5WLAA .
Ok, I am re-opening this sisue as not completely solved
Be aware that on 2.3.8, if you deselect the checkout forms in admin, checkout will completely break.