MediaWiki/Tickets/Phabricator T274807 - No CAPTCHA from ConfirmEdit served for users that use MobileFrontend: Difference between revisions

    From Consumerium development wiki R&D Wiki
    (+ T160262 - Add support for Google's new Invisible reCAPTCHA)
    (+ T203478 - Support No CAPTCHA reCAPTCHA in VisualEditor - marked as closed resolved)
    Line 22: Line 22:
    </pre>
    </pre>


    ''' Some related tickets I came across when searching for info / existing tickets '''
    ''' Some related tickets I came across when searching for info / existing tickets ''''
    * [https://phabricator.wikimedia.org/T203478 T203478 - ''Support No CAPTCHA reCAPTCHA in VisualEditor''] - marked as closed resolved
    * [https://phabricator.wikimedia.org/T128487 T128487 - ''Support more CAPTCHA modules of ConfirmEdit in the Api'']
    * [https://phabricator.wikimedia.org/T128487 T128487 - ''Support more CAPTCHA modules of ConfirmEdit in the Api'']
    * [https://phabricator.wikimedia.org/T64960 T64960 - ''Prototype CAPTCHA optimized for multilingual and mobile'']
    * [https://phabricator.wikimedia.org/T64960 T64960 - ''Prototype CAPTCHA optimized for multilingual and mobile'']

    Revision as of 13:00, 10 February 2021

    On Sunday 2021-02-07 I was alerted by User:Haitokin via the Consumerium Whatsapp hotline, that he was unable to edit the wiki using the mobile interface provided by mw:Extension:MobileFrontend, when not logged in.

    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.


    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 #mediawiki 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.