I've tested this fix by manually changing the public key in the page DOM to one I control (similar to what would be done in a real site key tampering attack), and then submitting the form: The API returns an error and the edit is not saved.

The patch was marked as WiP while addressing things raised during the code review.

In T410657#11427982, @hector.arroyo wrote:

After recent changes introduced during the code review this is not working anymore: I've been able to send an edit, get redirected to the edit form, and then resubmit the form without actually being asked to solve a captcha (i.e. the "always challenge" key was not there the second time).

After recent changes introduced during the code review this is not working anymore: I've been able to send an edit, get redirected to the edit form, and then resubmit the form without actually being asked to solve a captcha (i.e. the "always challenge" key was not there the second time).

As per this comment, we will be adding support for carrying the "always challenge" sitekey into other pages when it is first triggered as the consequence from another, so that if an AbuseFilter first triggers the captcha when editing page A and then the user edits page B wthout solving A's captcha, a new captcha is shown when trying to save page B (i.e. the "Always challenge" key is used on the first load of page B's edit form).

@EMill-WMF confirmed that the new messages are correct (the new messages are the same as before but without commas, i.e. "Please try again" instead of "Please, try again").

This is being fixed as part of T410657: hCaptcha: Improve support for SiteKey verification, os moving this ticket to code review since patches for that patch are currently being reviewed.

QA completed, closing this task.

The main patch (ConfirmEdit #1208333) was reviewed and merged yesterday, a backport (ConfirmEdit #1210737) is scheduled, a patch updating config (mediawiki-config #1210627) exists and a follow-up (ConfirmEdit #1210771) is being reviewed now, so moving this ticket to In Review.

I've updated the patch

@hector.arroyo Is this still blocking the patch?

Moving to 'In progress' since this is being worked on.

Updating the i18n message here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1208301

Moving this to QA in the team's board given that all patches have been merged and it is already in QA in the WE4.2 board

Note that a concerns have been raised about the inability of sending the form if the connection is lost after loading the edit form but before the used interacts with it (i.e. before there is a chance to load hCaptcha's SDK). This discussion is blocking merging that patch.

In T399177#11383092, @mszwarc wrote:

In T399177#11378169, @Niharika wrote:

I encountered this issue again today. The notice does not disappear after 30 seconds as it should.

Where have you encountered that? I observed an expected behavior today (both in wikitext editor and VE) on a local wiki (master branch) and testwiki.

In T409911#11379592, @hector.arroyo wrote:

@Niharika @EMill-WMF @kostajh I was thinking on using these messages for the errors raised during the hCaptcha execution:

"hcaptcha-internal-error": "There was an internal error while sending the form. Please, try again."
"hcaptcha-network-error": "There was a network error while sending the form. Please, ensure you have a working connection and try again."
"hcaptcha-rate-limited": "There have been too many attempts to solve the captcha. Please, wait a moment before trying again."

Does that sound ok to you?

If not, we can keep using the current generic message There was an error while loading the form. To continue, you will need to reload the page. or a new generic message stating that the user may retry the submission (something like There was an error while loading the form. Please, try again).

Patches have now been merged, so moving this to QA in the team board.

I've updated the patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1205186 to keep using the generic message for these cases ("There was an error while loading the form. To continue, you will need to reload the page.") while still allowing the user to resubmit the form.

@Niharika @EMill-WMF I was thinking on using these messages for the errors raised during the hCaptcha execution:

I've updated https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1205186, which is ready for review.

An initial patch (pending tests) was submitted to cover the case when the hCaptcha client lib reports a network error, so that the user is able to resubmit the form in this scenario: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1205186

Alternatively, you can switch the browser to Offline mode in the dev tools after the captcha popup has been shown but before hitting the Verify button.