reCaptcha show up twice on One Page Checkout
Kisumo opened this issue · 39 comments
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 👍
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 /var/log/recapctha.log
There may be a reason in there why its failed.
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] => sales@proxiblue.com.au
[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?
@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.
@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
@ProxiBlue , thanks a lot for your fast work here, that seems to work
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.
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.
Ok, https://github.com/ProxiBlue/reCaptcha/releases/tag/2.3.10
Notice that due to the changes in this ticket (to prevent double showing) there is no longer any difference between selecting Guest or Register at checkout options.
If either is selected, there will be a captcha for both in checkout.
I will need to rework the entire way I make the fix for this 'double display' work to solve that, and at this point I simply don't have the time.
I may very well just drop both options to one in a future release: Checkout reCaptcha
Damit, I am not winning with this one. I might have to re-loo at this entire fix.
I just foudn a site I manage not working on invisible on checkout!
Ha, no, my bad, the site had teh Tick Box API keys set, not invisible, once fixed, it works as expected! (phew)
FYI: I have a site (one only) that uses bog standard OnePage and multiple users on IOS devices claiming they cannot proceed past billing to next step.
Disabling reCapctha fixed issue / reports.
Neither myself, or client and his testers could reproduce this issue.
Just letting you know (in full disclosure) that it would seem latest changes seem to be causing some form of issue.
I am currently considering archiving this module, as I don;t have time to spend on it due to workload.
Just be aware there could be an issue excluding clients using site form actioning checkout.
@ProxiBlue , following #56 , I just installed the newest version.
Unfortunately, the invisible reCaptcha is not validated any more in the checkout.
Please activate the logging and try to go through the checkout. The fields are there, but no validation happens.
As far as I see, this is somehow related to your check in_array($this->_originalFormId, $this->_forms) in \ProxiBlue_ReCaptcha_Model_Recaptcha::isRequired.
This works when the question is if the check should be added, but not any more when it is called to decide if it should get validated or not.
Please be so kind and take another look into that.
1.9.4.5 with all Mage One Patches applied. But I actually expect it to be a general issue, independent of the Magento version. When I debug into $this->_originalFormId during the actual validation step, this is also recapctha_checkout, so it's never in $this->_forms and this is why nothing gets validated
Ok, I honestly don't have the time right now to debug this. I had a cursory glance at the code, and to be frank, it has become a bit of a hacky mess, and likely requires a major refactor
Due to my current schedule, and paid for deadlines, I simply cannot spend time on this for a few weeks.
I am at present considering to archive this module, as I woudl prefer to not have a broken module available for general use.
The only thing that change din the latest version is the usage of prototype 1.7.1, which could also be involved with the issue.