Closed (fixed)
Project:
reCAPTCHA v3
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Jun 2020 at 13:50 UTC
Updated:
15 Jan 2021 at 21:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
casey commentedComment #3
jedihe commentedI just tested #2 and it works great:
Without the patch:
With the patch:
Tested in Chrome 83.0.4103.61.
As for code review, just a minor coding standards find:
", function"
Comment #4
jedihe commentedComment #5
mrinalini9 commentedComment #6
mrinalini9 commentedUpdated patch #2 along with the changes suggested in #3, please review.
Comment #7
casey commentedThe non-ajax form solution doesn't work: form submissions won't contain the value of the triggering element. Still looking for a working solution.
Comment #8
jedihe commentedEDIT: confirmed, the triggering element is missing from the POST'ed form data :/.
@casey, are you fully sure of that? non-AJAX forms are working fine for me with #2:
1. I get the invisible reCaptcha check triggered when I try to submit the form, *before* the actual form submission is triggered.
2. The form submission contains the correct POST data (copied from DevTools/Network):
Comment #9
jedihe commentedLet me take a stab at this; I'll try to replace the onSubmit handlers with the one to handle reCaptcha v3 validation, then restore the other handlers and do form.requestSubmit(trigger) in the callback.
Comment #10
casey commentedform.requestSubmit &SubmitEvent.submitter are not supported in IE
https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement/request...
https://developer.mozilla.org/en-US/docs/Web/API/SubmitEvent/submitter
A polyfill that covers all situations doesn't seem possible...
Comment #11
jedihe commentedOh, didn't check compatibility at the beginning... :(.
Is there any way to resolve the reCaptcha v3 in a synchronous manner for browsers not supporting requestSubmit() and .submitter? if that's possible, then the submission blocks until the token is resolved, then just let the submission flow continue as normal; now, for this to work, I'm assuming that the form submission picks up the new data, set on-the-fly.
Comment #12
jedihe commentedComment #13
casey commentedMaybe we should just refresh the token every 60 seconds.
Comment #14
jedihe commentedComment #15
jedihe commentedAlright, I managed to get 'op' parameter be preserved on non-AJAX submissions; I just injected a hidden input to mirror the submit button that was clicked, since formElement.submit() only ignores [type=submit] elements.
Quick checks on an AJAX submitted form showed it still working fine.
Tested on Chrome 83.
Comment #16
jedihe commentedComment #17
jedihe commentedUpdated patch to not assume a specific name attribute of the submit button.
Comment #18
jedihe commented@casey: although I considered your idea about refreshing the token every 60 seconds, I didn't try that approach since it would have required quite a big refactor of the patch. #17 was done trying to leverage the previous work as much as possible.
Comment #19
casey commentedThis patch uses the approach of updating the tokens every 90 seconds.
@jedihe, I am afraid that blocking/delaying form submits will cause all kinds of issues, since we don't have total control over how forms are being submitted.
For example, form.submit() won't trigger a new submit event. Other code can no longer be sure if a form has been submitted.
The ajax solution seems to work fine, but then again, we can't be sure how a form is being submitted.
The only solution that I can come up with, is using a timer and fetch new tokens just (30 seconds should be enough to send an process requests) before they expire.
Comment #21
dench0Thanks, applied.
Comment #23
khaled.zaidan commentedCould we please also get this done on the D7 version?
I'll do a patch shortly backporting the #19 for D7 and upload here.
Comment #24
dench0Comment #26
dench0Comment #27
jedihe commentedI can confirm #20 + #25 work for me, tested on D 8.9, in a form submitted via AJAX.