I filed that yesterday as bug 46072https://bugzilla.wikimedia.org/show_bug.cgi?id=46072. ;)
I'll try to find time to review it before the weekend.
On Thu, Mar 14, 2013 at 3:55 PM, Brion Vibber bvibber@wikimedia.org wrote:
As some folks may recall, an action=createaccount was added to the API a few weeks ago. Unfortunately the first pass didn't include CAPTCHA support, so we haven't been able to use it for the live sites yet (which use ConfirmEdit's "FancyCaptcha" mode). We expect to start using this in the next couple weeks for the mobile Commons apps, so it's time to make it captcha-friendly...
I've made a first stab at adding support, based on the existing captcha interfaces for login and editing:
MediaWiki core: https://gerrit.wikimedia.org/r/53793 ConfirmEdit ext: https://gerrit.wikimedia.org/r/53794
So far I've tested it with the default 'math captcha' mode, with this test rig: https://github.com/brion/mw-createaccount-test
If a captcha needs to be run, action=createaccount will spit back a result including a 'captcha' field including several subfields, such as in this example: https://www.mediawiki.org/wiki/API_talk:Account_creation#Captcha_additions
Since account creation requires a first request to get a token anyway, this shouldn't significantly add to the complexity of using the API.
Text captchas will have a 'question' subfield to be presented; image captchas will have a 'url' field which should be loaded as the image. 'type' and 'mime' will vary, and probably shouldn't be used too closely.
Pass back the captcha id field in 'captchaid' and the response word in 'captchaword' parameters along with the final request, and it should pass the captcha. If the captcha doesn't pass, you get back new captcha info and can continue.
Questions:
- Does this seem to make sense? :)
- Will other API users kill me for this or will it be easy to use?
- Any surprises that may turn up?
- Any bugs/style problems in my code so far?
-- brion
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
On 03/14/2013 04:01 PM, Brad Jorsch wrote:
I've made a first stab at adding support, based on the existing captcha interfaces for login and editing:
MediaWiki core: https://gerrit.wikimedia.org/r/53793 ConfirmEdit ext: https://gerrit.wikimedia.org/r/53794
Side note, there is also an in-progress API for getting a new FancyCaptcha (https://gerrit.wikimedia.org/r/#/c/44376), used for a "refresh captcha" button.
Matt Flaschen
On Thu, Mar 14, 2013 at 3:55 PM, Brion Vibber bvibber@wikimedia.org wrote:
MediaWiki core: https://gerrit.wikimedia.org/r/53793 ConfirmEdit ext: https://gerrit.wikimedia.org/r/53794
So far I've tested it with the default 'math captcha' mode, with this test rig: https://github.com/brion/mw-createaccount-test
This is great to see.
Using your test rig or Special:APISandbox, the API return warns about "Unrecognized parameters: 'wpCaptchaId', 'wpCaptchaWord" when I get the captcha wrong.
It seems if the user gets the captcha wrong, there's no explicit indication like captcha-createaccount-fail ('Incorrect or missing confirmation code.'). Instead the API reports a generic Failure result, and the UI presents a new captcha.
ConfirmEdit has a getMessage() to provide action-specific text like fancycaptcha-createaccount. Perhaps the API should pass that back as well. Otherwise the UI has to know the details of the captcha in use so it can get a message for it.
The current CreateAccount form submission to Special:UserLogin reports many form errors like username exists, password wrong, etc. before it runs the AbortNewAccount hook where ConfirmEdit checks the captcha. But APICreateAccount runs the APICreateAccountBeforeCreate hook early, before it dummies up a login form and calls the same validation. So users will go through the frustration of getting the captcha right before being told their username isn't available or their password isn't long enough.
There's also the weirdness that ApiCreateAccount winds up checking the CAPTCHA twice. AIUI, here's the program flow:
ApiCreateAccount() Runs APICreateAccountBeforeCreate hook (captcha may abort) Creates a login forms and call $loginForm->addNewaccountInternal(); addNewaccountInternal(): Does a bunch of form validation Runs AbortNewAccount hook (captcha may abort, also TitleBlacklist, AntiSpoof, etc. may abort)
If ApiCreateAccount() could tell there was a captcha failure within addNewaccountInternal and could ask the captcha to addCaptchaAPI() to the result, then we wouldn't need the new APICreateAccountBeforeCreate hook.
It would be nice if captcha was always checked on its own hook instead of sharing a hook with other extensions. That would let a future validation API run the username past TitleBlacklist and AntiSpoof without getting shot down by the captcha.
Cheers, -- =S Page software engineer on E3
wikitech-l@lists.wikimedia.org