Requires core update I6ae34c0 to actually send the message key back
in the error response. On older MediaWiki versions, behavior should
remain unchanged.
Bug: 60008
Change-Id: If9cc08e44d1d2efacf817b8c6cbb2d71a4e8b692
Hooks used:
* AddNewAccountApiForm
* AddNewAccountApiResult
This adds a 'captcha' section to the results with the same format
as we provide for editing; you'll get this for instance at the
same time as you do a first-request that prompts for a token.
No modification to the result status is included; presence of
the 'captcha' section is assumed to be enough to prompt the client
to fetch and render the captcha prompt.
Failure to pass a captcha will return an API error message; a
subsequent commit fixes problems with that error message being
hard to machine-read.
Note that logic from inside Captcha::confirmUserCreate has been
pulled out to Captcha::needCreateAccountCaptcha so we don't
send captcha information to users who don't need it.
Requires core changes: If5b7dab8
Sample API client: https://github.com/brion/api-createaccount
Bug: 46072
Change-Id: Id628defaeab2bf5979ca8f4284d14fc42d9c3e46
The ReCaptcha module was not injecting its parameters at all, so they
were not showing up in the auto-generated help. This is now fixed.
Also, the API recently added a new parameter to the APIGetAllowedParams hook
to differentiate between fetching the allowed parameter list for help
output and fetching it for processing within the module. ConfirmEdit
only needs to inject the parameters for the former, so it should check
this parameter if available.
Change-Id: Ia8c9a8b882ee3480b71bfb3f2345475506549819
Left setting of wpCaptchaId and wpCaptchaWord in core. Can't think of a sane way to check and set them via an extension (subclass and override, or a hook). Annoyingly APIEditBeforeSave doesn't pass the params array
