There is no need to run tests with enabled Captchas, because these tests
doesn't cover captchas.
Bug: T44145
Change-Id: I52ce63e08a1b71ba92642834c5dfbe3d2149f822
Insert Captcha direct after click on Edit over editpage buttons, instead of
show after click on save. If the captcha was incorrect or empty, show
error message at old captcha position.
Bug: 19648
Change-Id: Ia3bb66f98aa84bb6efb7a1e42fbc203b401e99b8
ConfirmEdit was tripling the API save time, because it was parsing the
entire content twice to evaluate whether the addurl trigger is hit.
While I was here, I stopped using the deprecated non-Content hooks. The
new hook, EditEditFilterMergedContent, does not pass an EditPage object,
which means that Title or WikiPage objects need to be passed around
instead. Also, since EditPage::showEditForm() cannot be called with no
EditPage object, use a EditPage::showEditForm:fields hook instead.
If non-wikitext content is edited, assume that the regex trigger is not
hit.
For further architectural details, see the associated core change:
I4b4270dd868a . MW_EDITFILTERMERGED_SUPPORTS_API is a constant
introduced to detect the presence of the associated core change.
Also, in APIGetAllowedParams, set the allowed parameters even if we are
not on the help screen. This allows API users to submit their CAPTCHA
answer without it failing with an "unrecognized parameter" error.
Compatibility with MediaWiki 1.21 is retained, compatibility before that
is dropped.
Change-Id: I9529b7e8d3fc9301c754b28fda185aa3ab36f13e
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
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
* Set the default to 3 instead of 1, to be more forgiving of mistyped passwords. Unlikely to help bots much; quite likely to help blind people who aren't really really really careful typers.
* Commit some whitespace change I had lying around.
* Hooking into the APIEditBeforeSave hook (which will appear in the ApiEdit_Vodafone branch in the next revision)
* Moved general CAPTCHA generation in SimpleCaptcha to getCaptcha()
* Moved general confirmEdit() functionality to doConfirmEdit() to facilitate differtiating between UI and API handling
* Adding SimpleCaptcha::addCaptchaAPI() method that adds CAPTCHA information to an API result array. Other CAPTCHA implementations should override this method with a function that does the same (did this for FancyCaptcha and MathCaptcha)
