Page MenuHomePhabricator

No CAPTCHA from ConfirmEdit served for users that use MobileFrontend
Open, Needs TriagePublicBUG REPORT

Description

An user informed me he was unable to edit a wiki that is my responsibility using the mobile interface provided by mw:Extension:MobileFrontend, when not logged in.

After looking into the issue a little bit and also receiving help, it seems to be because the MobileFrontend does not correctly include the CAPTCHA provided by/via mw:Extension:ConfirmEdit.

See irc log cutlets at end for some proficient insight on the issue from _tgr

Steps to Reproduce:

  1. Activate ConfirmEdit and MobileFrontend
  2. Set CAPTCHA type to ReCaptchaNoCaptcha
  3. Access wiki in mobile mode and try to do something for which CAPTCHA should be invoked.

Actual Results:

  1. A box stating "Enter confirmation code" shows up, no CAPTCHA

Expected Results:

  1. CAPTCHA is served to mobile users normally.

Information:

This is probably due to mw:Extension:MobileFrontend not fully supporting mw:Extension:ConfirmEdit. This seems to be a semi-known issue.

The documentation of MobileFrontend does not claim that it supports ReCaptchaNoCaptcha, but the ones it supports are even weaker and we are having problems of bots passing the current CAPTCHA. hCaptcha could be more suitable.

I hope this can be fixed. Also any solid-ish workaround solution would be helpful.

Relevant wiki configuration :

MediaWiki version: 1.35.1 (ffed6e6) 07:03, 8 January 2021

$wgMFAutodetectMobileView = true;
$wgMFAdvancedMobileContributions = true;
wfLoadSkin( 'MinervaNeue' );
$wgMFDefaultSkinClass = 'SkinMinerva'; 
wfLoadExtension( 'MobileFrontend' );

wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) );
$wgCaptchaClass = 'ReCaptchaNoCaptcha';

Some related tickets I came across when searching for info / existing tickets

Relevant parts from irc conversation in the mediawiki-mediawiki channel on freenode on 2021-02-07

(used with permission, redacted irrelevant parts, my nick is Iamahuman)

  • [sunnuntaina 7. helmikuuta 2021] [15.02.42 EET] <Iamahuman> Hi. An user just contacted me an informed me that he is unable to submit changes anonymously on mobile. The text "enter confirmation code’ appears, no CAPTCHA. Am Using reCAPTCHA v2 iirc
  • [sunnuntaina 7. helmikuuta 2021] [15.04.31 EET] <Iamahuman> I googled for it and found it on line 41 of https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/i18n/en.json. The line reads as follows: "mobile-frontend-account-create-captcha-placeholder": "Enter confirmation code",
  • [sunnuntaina 7. helmikuuta 2021] [16.24.14 EET] <tgr_> Iamahuman: are you using ConfirmEdit?
  • [sunnuntaina 7. helmikuuta 2021] [16.28.38 EET] <Iamahuman> tgr_: Yes, I am
  • [sunnuntaina 7. helmikuuta 2021] [16.29.06 EET] <Iamahuman> and the reCAPTCHA invisible captcha does not work for my mobile users
  • [sunnuntaina 7. helmikuuta 2021] [16.30.35 EET] <tgr_> is it a public wiki?
  • [sunnuntaina 7. helmikuuta 2021] [16.30.40 EET] <Iamahuman> yes
  • [sunnuntaina 7. helmikuuta 2021] [16.31.45 EET] <tgr_> Iamahuman: can you share a link?
  • [sunnuntaina 7. helmikuuta 2021] [16.31.49 EET] <Iamahuman> tgr_: https://develop.consumerium.org/wiki/Main_Page
  • [sunnuntaina 7. helmikuuta 2021] [16.33.17 EET] <tgr_> oh, you are using ConfirmAccount?
  • [sunnuntaina 7. helmikuuta 2021] [16.36.18 EET] <Iamahuman> tgr_: Using ConfirmAccount and ConfirmEdit ... hordes of bots hit in 2008 and 2010
  • [sunnuntaina 7. helmikuuta 2021] [16.40.04 EET] <tgr_> Iamahuman: oh, sorry, I thought the problem was during signup. I see now you were talking about editing.
  • [sunnuntaina 7. helmikuuta 2021] [16.40.32 EET] <tgr_> That's pretty hopeless, MobileFrontend replaces the edit interface entirely.
  • [sunnuntaina 7. helmikuuta 2021] [16.43.16 EET] <tgr_> I suppose you can intentionally break MobileFrontend's routing
  • [sunnuntaina 7. helmikuuta 2021] [16.43.38 EET] <tgr_> something like https://develop.consumerium.org/w/index.php?title=Research/US/How_to_find_out_who_owns_what&action=edit#/xxx won't get hijacked because there already is a route
  • [sunnuntaina 7. helmikuuta 2021] [16.43.55 EET] <tgr_> so maybe you can add that to edit links somehow
  • [sunnuntaina 7. helmikuuta 2021] [16.44.07 EET] <tgr_> or maybe there's a proper way to disable the edit overlay in MF
  • [sunnuntaina 7. helmikuuta 2021] [16.46.45 EET] <Iamahuman> tgr_: I don't quite understand it, but that link you posted, in a non-logged-in browser, does show the reCAPTCHA, whereas normally it doesn't show up
  • [sunnuntaina 7. helmikuuta 2021] [16.47.01 EET] <Iamahuman> in the mobile view
  • [sunnuntaina 7. helmikuuta 2021] [16.47.35 EET] <tgr_> yeah because it has a fake route, which prevents the MobileFrontend logic from rerouting it to the mobile edit form
  • [sunnuntaina 7. helmikuuta 2021] [16.48.22 EET] <tgr_> another trick would be to create an edit link with action=submit instead of action=edit
  • [sunnuntaina 7. helmikuuta 2021] [16.52.11 EET] <Iamahuman> rather no tricks, but a reliable documented way of circumnavigating this problem
  • [sunnuntaina 7. helmikuuta 2021] [16.53.58 EET] <Iamahuman> At least now I know of this problem, previously I had no idea of this existing. Hopefully someone fixes it. It would seem to me (but not sure) that the Mobile Frontend should somehow be different so that the CAPTCHA would be displayed as it is to web users
  • [sunnuntaina 7. helmikuuta 2021] [19.47.18 EET] <Iamahuman> [18:00] <tgr_> Iamahuman: MobileFrontend implements its own edit form. It would have to implement its own captcha handling too. Or rather, provide a hook point (maybe it does that already) for ConfirmEdit to implement.

Event Timeline

Jdlrobson added a subscriber: Jdlrobson.

A problem with ConfirmEdit should have nothing to do with the MobileFrontend extension. Presumably ConfirmEdit needs to use a hook provided by MobileFrontend.

matmarex added a subscriber: matmarex.

A problem with ConfirmEdit should have nothing to do with the MobileFrontend extension. Presumably ConfirmEdit needs to use a hook provided by MobileFrontend.

MobileFrontend does not have any such hook (perhaps it should). It just hard-codes the interface necessary for a few types of CAPTCHAs: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/41fe6be8d47b45c137d6fd5547a3a855e7c599f6/src/mobile.editor.overlay/EditorOverlayBase.js#L663

This bug does not affect VisualEditor. It supports ReCaptchaNoCaptcha since T203478.

MobileFrontend does not have any such hook (perhaps it should). It just hard-codes the interface necessary for a few types of CAPTCHAs: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/41fe6be8d47b45c137d6fd5547a3a855e7c599f6/src/mobile.editor.overlay/EditorOverlayBase.js#L663

Right... yeh that's not great. Presumably whatever's happening for desktop needs to also happen in the mobile editor (ideally using the same hooks)

This bug does not affect VisualEditor. It supports ReCaptchaNoCaptcha since T203478.

Off topic, but I was told before that anything about the editor should be tagged VisualEditor. Is Editing-team the best one to use now?