Why:
- There are issues with the current "showcaptcha" action, and we need to
disable it until the problems are fixed
What:
- Define a feature flag to enable custom actions. For now, nothing is
enabled.
Bug: T20110
Change-Id: I3484d66298bc9f49dfbe003a0605e2ac1a092e10
Why:
- We want to allow administrators to invoke a CAPTCHA
if an AbuseFilter is configured to do so.
What:
- Implement the AbuseFilterCustomActions hook and define
CaptchaConsequence, which will inform AbuseFilter's implementation
of onConfirmEditTriggersCaptcha that it should show a CAPTCHA
- Deliberately do not register the "showcaptcha" action as a "dangerous
action", because filters that use this action are aimed at bot
traffic, and we don't want a bot to be able to get past the
"showcaptcha" action just by making repeat requests
Soft depends on I110a5f5321649dcf85993a0c209ab70b9886057c
Bug: T20110
Change-Id: Ie87e3d850541c7dc44aaeb6b30489a32a0c8cc60
This allows the dynamic activation of CAPTCHAS triggering without the
need to change the configuration.
This lays the foundation for stewards to later be able to activate
'emergency captchas' via an on-wiki interface.
Bug: T303433
Change-Id: If48689fe068aa3ec56e51e01b84cf25c63bcbf0b
Since AbstractAuthenticationProvider ::setLogger, ::setManager,
::setConfig, ::setHookContainer methods had been soft deprecated,
so its usages were removed. AuthenticationProviderTestTrait
::initProvider was used in order to initialize
CaptchaPreAuthenticationProvider in the test.
* Also bump required MW version to 1.37.0
Bug: T281993
Change-Id: I9a139433b089597a2a5dfb7e23338fc8f7183b47
I've left alone the pass-through hooks into the sub-extensions for now.
That'll be the next patch
Bug: T269882
Change-Id: I62eedd4afc36b4610a138b84b02d2cc48ce0ae2f
* ext.confirmEdit.CaptchaInputWidget.js:
Based on code from ve.init.mw.CaptchaSaveErrorHandler.js
* ext.confirmEdit.CaptchaInputWidget.less:
Based on code from mw/ext/VE repo in ve.ui.MWSaveDialog.css
* ConfirmEditHooks.php:
Based on code from mw/ext/VE repo in VisualEditorHooks.php
Change-Id: I6605017fd31a4f96c529dd0beb69e9f4433cebc1
This is one of the last extensions to be converted to having
the API messages in a separate file (at least out of the extensions
that are used be Wikimedia).
This one is a bit different from the others because it actually as several
extensions with separate i18n files, so it requires extra-careful review,
especially in Gruntfile and the extension.json files.
Bug: T189982
Change-Id: I66faae6fd4ff447327587c89ad2a1704edd1b356
This can be merged before the code is dropped from VE, as
it will just overwrite the registry entry.
Bug: T141676
Depends-On: I2c35b9443208928db43bcfd515864641b10cc602
Change-Id: I2fa7ca7203e0a82f5ce9b79e2642dba2baba6c5a
See I2291c69d9df17c1a9e4ab1b7d4cbc73bc51d3ebb for the anticipated
hard-deprecation of this method in core.
Bug: T197492
Change-Id: I08b5c7b0c8cc1b88f07163cfd412e5d7e87c56f3
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: Ifa6b2480400a161fd931a4ab456c0dcaa809459e
Instead of misusing the config section of extension.json to declare
captcha triggers in the ConfirmEdits CaptchaTriggers config variable,
other extensions can now use the CaptchaTriggers attribute for the
exact same thing. E.g., to declare a new trigger, the following
addition to the own extension.json will register the trigger in
ConfirmEdit:
"CaptchaTriggers": {
"wikiforum": true
}
This also removes the CaptchaClass config from the main extension.json
config section, and automatically sets the SimpleCaptcha module in the
getInstance() method of ConfirmEditHooks, which is a pre-requirement for
the mediawiki/core change Ieeb26011e42c741041d2c3252238ca0823b99eb4.
Bug: T152929
Change-Id: I4c5eaf87657f5dc07787480a2f1a56a1db8c714f
The value of $ceAllowConfirmedEmail is copied to $wgAllowConfirmedEmail if
set in LocalSettings.php for backward-compatibility. However, a deprecation
warning is emitted in this case.
Bug: T162641
Change-Id: If4daf6f25f0d2b2c0f1e173ee3903063a39978bb
Since this extension uses extension.json, it already requires 1.25+ so
no need to keep the old code around.
Change-Id: I31b96b0939d5321be31889422cfc703c9c6c2baa
The user now can press the preview button to bring up an interpreted list
of the lines of the interface message MediaWiki:Captcha-ip-whitelist to check
if the added/remained data is (still) a valid list of (whitelisted) IP addresses.
Bug: T129757
Change-Id: Ic61f00e7f88c9290ae6e11f7258c11a730ac98c8
It was only needed for MediaWiki prior to 1.25
(09a5febb7b024c0b6585141bb05cba13a642f3eb).
We no longer support those versions after
1d08dd07b8.
Bug: T137832
Change-Id: I27f244631e9dcd160bffff70349e5034f2a537ea
Also update MathCaptcha so that it works with recent versions of
Math (and breaks with old ones). Also fix MathCaptcha API output,
which used to send the question in plaintext.
Bug: T110302
Change-Id: I0da671a546700110d789b79a3089460abd9cce3b
Depends-On: I8b52ec8ddf494f23941807638f149f15b5e46b0c
Local administrators can now use [[MediaWiki:Captcha-ip-whitelist]]
page to exempt specific IP addresses and IP ranges from captchas.
This is useful for modifying in a short notice such as editathons and
other events like this where captchas add unnecessary complexity for
new users.
The page is disabled by default and IPs should be added separated by
newlines. If any other character is found on a line, it will be ignored
but leading and trailing whitespace characters are allowed.
Bug: T103122
Change-Id: I54866b5bfca80debcf3d3fb7963932ed03b48548
Use a default setting of > 20 logins in 10 minutes. In order to
achieve this many with core's default throttle's, you would have
to be attempting to login from at least 2 IP addresses.
Bug: T122164
Change-Id: Id3ea766cfb7d50444082275a628b8b2aa10e6050
