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
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 Thu, 14 Mar 2013 12:55:16 -0700, Brion Vibber bvibber@wikimedia.org wrote:
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.
Some captchas (iirc ReCaptcha) won't give you easy access to the image. And this plan won't be compatible with the variety of new captcha types like the KittenAuth-like category of CAPTCHAs. Differentiating between the types just to support text CAPTCHAs (which are really the easiest CAPTCHAs to break) also sounds unfortunate.
We might just have to do something that outputs a blob of html or a url to a html document (either perhaps as a frame url or a url to fetch the blob of html from).
On Fri, Mar 15, 2013 at 11:47 PM, Daniel Friesen <daniel@nadir-seen-fire.com
wrote:
On Thu, 14 Mar 2013 12:55:16 -0700, Brion Vibber bvibber@wikimedia.org wrote:
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.
Some captchas (iirc ReCaptcha) won't give you easy access to the image. And this plan won't be compatible with the variety of new captcha types like the KittenAuth-like category of CAPTCHAs. Differentiating between the types just to support text CAPTCHAs (which are really the easiest CAPTCHAs to break) also sounds unfortunate.
I should point out that I haven't invented this just now; this system has been in place for at least a couple of years for action=edit and action=login.
We might just have to do something that outputs a blob of html or a url to a html document (either perhaps as a frame url or a url to fetch the blob of html from).
*nod*
Let's make it a URL if possible; that can be exposed as an iframe in web apps or a web view of some kind for native apps, without exposing HTML injection.
If we get all the captcha plugins retrofitted it'd be great to document the system better for bot & client tool authors. :)
-- brion
On Thu, Mar 14, 2013 at 12:55 PM, Brion Vibber bvibber@wikimedia.orgwrote:
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
I've also confirmed now that it works with FancyCaptcha, which is what we still use on the Wikimedia sites.
The gerrit patchsets have been updated for consistency with the other API modules already providing the captcha interface, such as ApiEdit and ApiLogin: * return result=Failure instead of result=needcaptcha for consistency (presence of the 'captcha' field takes care of discovery) * fix a case where an extension that used the hook but didn't return error data would fall through to create account * a little general cleanup
I've noticed that a lot of the discussion in this thread has been questioning whether support for non-default captcha modules will work and how; we should consider the API captcha interface still provisional, but note that it already exists and is in usage for edit captchas and login throttling!
[I like the idea of being able to provide an HTML blob or iframe link, which might work for things like recaptcha... note that there *is* support in ConfirmEdit's ReCaptcha module for the API responses but I haven't tested to confirm it works.]
Any further issues that would delay short-term adoption of this addition? I'd love to get it live in the next week or two so we can start using it in the Commons apps for Android and iPhone. :)
-- brion
mediawiki-api@lists.wikimedia.org