Added a check for 'badcaptcha' ratelimit. This enables administrators
to limit users trying to solve captchas just by playing around.
By default there is no ratelimit set, it has to be set explicitly in
LocalSettings.php.
Bug: T48292
Change-Id: I8fc66f9884288c4596b8b4045010cdaa421a1412
The code for the hook is passing in an empty new-text, so there's no
point in parsing that and the existing page text for links.
We pass false to shouldCheck's $isContent parameter (and an empty string
for $content) because getting a Content would break compatibility with
1.21, which we specifically preserved in I9529b7e8.
This also kills two entirely-unused parameters to the recently-added
SimpleCaptcha::editShowCaptcha().
Bug: T88661
Change-Id: Ie8a2d4da4c5bf0dcc8977172debbeb5913b56191
There is no need to run tests with enabled Captchas, because these tests
doesn't cover captchas.
Bug: T44145
Change-Id: I52ce63e08a1b71ba92642834c5dfbe3d2149f822
CAPTCHA classes should always be possible to detect the actual action,
which triggered the CAPTCHA. E.g. to add special fields in getForm().
Change-Id: Ie95305b2e6dcbf527a23c92613755092185e6a05
Captcha.php inserts captcha in the header of Userlogin and Usercreate template.
This leads to inconsistent view because js,if enabled, moves the captcha before
submit button. Now the captcha is inserted at the 'extrafields' parameter just
before submit button in both the templates,for uniformity of view.
JS functionality in
resources/src/mediawiki.special/mediawiki.special.userlogin.common.js migrated
to backed in FancyCaptcha.class.php, so that the FancyCaptch is already styled
and positioned before 'submit'.
Depends on I82c68814e79cbc5aa250a308862c59fcbb6fd527
Depends on Ie95305b2e6dcbf527a23c92613755092185e6a05
Bug: T85192
Bug: T87190
Change-Id: If9a68aaee2cf98d63647816ccc8fc0bad12ca3d3
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
