Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: Ifb189a3fcacc971ff43ff44d5ffc564f068a7da0
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I60968f9b735b27eaef20e5d42af322a8c2ecd257
Some of this is not necessary at all because all properties are
public anyway.
In other cases only one property needs to use the wrapper, the rest
is public and can be accessed normally.
In other cases we just missed the @var annotation to make the IDE
aware of what's actually going on.
Change-Id: I29b526ee3aad9f0c9671fb133c625b9f14309db9
HashConfig is a rather trivial value class with not much behavior.
The complexity of an actual moc is not needed here, it seems.
Change-Id: I80025e67f248889ffff4d7237793e7d83dd269d5
These providers don't really do anything but provide the two possible
booleans. That's it. Why not make the code say that?
Change-Id: I0cbca6222e8130d504494ae86b1a963a92430a61
Why:
- In the production WMF deployment of AbuseFilter and ConfirmEdit, we
load ConfirmEdit first, then AbuseFilter. That means that
ConfirmEdit's onEditFilterMergedContent hook fires before
AbuseFilter's. The problem is that AbuseFilter uses
onEditFilterMergedContent to evaluate its rules and consequences, so
an AbuseFilter rule that defines a "showcaptcha" consequence becomes a
no-op, as it fires after ConfirmEdit has already decided to show or
not show a CAPTCHA to a user.
- All of that is to say: we need a way to tell ConfirmEdit to show a
CAPTCHA at the time that AbuseFilter's consequences are invoked,
which could be before or after ConfirmEdit's EditFilterMergedContent
hook invocation, depending on how the wiki has decided to load the
extensions
What:
- Define a flag for "shouldForceShowCaptcha", that other extensions can
set on the SimpleCaptcha base class to indicate that ConfirmEdit must
show a CAPTCHA (users with "skipcaptcha" right are still exempt)
- Check the isCaptchaSolved() and shouldForShowCaptcha() flags in
::triggersCaptcha, and also check if ConfirmEdit's
EditFilterMergedContent hook already ran
- In CaptchaConsequence, set the forceShowCaptcha property on the
SimpleCaptcha base class
- [misc] Add getter/setter for the captchaSolved property and the other
new class properties
Depends-On: I7dd3a7c41606dcf5123518c2d3d0f4355f5edfd3
Bug: T20110
Change-Id: Idc47bdae8007da938f31e1c0f33e9be4813f41d7
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I325f5bab163cddf76dbf8d5a6eca35a7ed7b6df7
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
