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
Follows-up 5b3765f7b, which refactored the way this was set.
Introduced in 2016 with 31c59374a, but redundant since 2020 with
commit c6c62e2c8f in MediaWiki core.
Bug: T139216
Change-Id: Iaf0a2f60833797ecf0b74f69dd797ca3c53cc550
ConfirmEdit will try to mess with ObjectCache::$instances, clean this
up so that we migrate consumers to go through ObjectCacheFactory.
Bug: T358346
Change-Id: I317a1a17f4f39e99a9b31660eebcd0185adb88f8
This has nothing to do with CAPTCHA generation, and the only thing it
needs from the SimpleCaptcha class is checking whether a CAPTCHA on
bad login is enabled at all.
Also improve comments in CaptchaPreAuthenticationProvider. I found the
session flag business really difficult to understand.
Change-Id: I8200531718aaa11effcb07539204e1a05ed432e0
Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: Id44f211320e56bc83e4c8f243369dc4eb562cf37
Add a basic unit test for HookRunner to improve coverage and
validate arguments between hook runner and hook interfaces.
Change-Id: Ib0c1f79fe724c1567081cec62894e2d35d00b812
The method was renamed in PHPUnit 9.
Done automatically with:
grep -rl assertRegExp tests/ | xargs sed -r -i "s/>assertRegExp\(/>assertMatchesRegularExpression\(/"
Also extend MediaWikiIntegrationTestCase, so that it can use the
forward-compatible assertMatchesRegularExpression method.
Bug: T243600
Change-Id: I6859b48f7a9084101e981fb48449c1c1dc17a80c
It's internal, extensions should not rely on it. And now it is being removed.
Needed-By: I85324d04ecde38aad5f827c7aa33d989089e6d33
Change-Id: Id981f5f110789c5b7daa64185ec8ad952914ab48
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
The code was setting $wgHooks['PingLimiter'] to a Closure rather than
an array of callables, which resulted in the hook never actually being
called.
Interesting that that didn't make any of the tests fail. Anyway, let's
switch to using the setTemporaryHook() method now provided by MW's base
test class.
Change-Id: I6ac22b3c43735dcab4920de827bf06e25f9adc04
The service LocalClusterObjectCache (to be introduced
in I39b03b1078efde3d9bc721d9d0c3694988c53a67) is not yet available.
The change linked above introduces it, but still relies on ObjectCache
because of tests of other extensions. ConfirmEdit's tests therefore
should always set ObjectCache::$instances, regardless of the existance
of the LocalClusterObjectCache service.
Change-Id: Ide340b7295ebe63a4efcfe6ec4381eb6697f8335
This breaks later tests, e.g.:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/450433https://gerrit.wikimedia.org/r/c/mediawiki/core/+/465423
The only reason this didn't cause test failures until now is because the
namespace data was getting (incorrectly) cached in between tests. As
soon as we start resetting namespaces for each test, namespaces set by
the extension registry get wiped out by these tests.
Change-Id: Icb7a4a2a5d19fb1f2453b4b57a5271196b0e316d
So we don't need to hackily deal with ExtensionRegistry internals.
Depends-On: I9e62a02ed2044c847e9ab2dcdfab094001f88986
Change-Id: Id6ca6eb49db789dbb3f227533c4442506cc61bc4
This doesn't work in PHP 7.2, because 'object' is no longer a valid
class name. stdClass works fine.
Change-Id: I47375fdf2f36ff62985b2e8c90fa0e5230273984
As a direct effect
- sending emails and creating accounts now respects $wgAllowConfirmedEmail
- log messages get a bit less verbose for mail sending and creating
accounts (but should be clear from the context what action was
performed)
- less code duplication \o/
Indirectly, this should make solving the attached bug easy(tm), because it
just needs to add a hook to the canSkipCaptcha function.
Bug: T176589
Change-Id: Id27b0eadbab7300b9e6969d406fa6f00ef0888bf
The captchas in production are registered conditional, in tests the
class needs to be added to the autoloader.
Moved this register up to setUp to detect the existing @covers correctly
by the new testValidCovers from
I1d564bcae2bfbedb004c440b90db6341148ed4ba
Change-Id: I79f225126d7bbbfd436ab165bb98a0ed9517b8bc
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
