Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I60968f9b735b27eaef20e5d42af322a8c2ecd257
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
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I908691348d259d868f39a7737614be82c9ce0c75
In this patch, we can now make use of MicroStash only and
drop dead code.
At this point, we're sure that there are no captchas in the
main stash, freeing up this memory for other requests to use.
Bug: T336004
Change-Id: I6aa69636f2f94e3bd18afc66eac37146d00771d1
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
ConfirmEdit uses MainStash as the backend to write its captchas. We
are migrating this extension to use the MicroStash store instead which
is more suitable.
This patch will store the captcha in MicroStash, read it from there
or fallback to MainStash if lookup was not successful. The code will
then clear both stores once after processing.
Migration plan
==============
step .1: Write to microstash store only, read from it or
fallback to mainstash store. Then delete from
both backends.
step .2: Read from microstash store only, delete from the
microstash store, and remove dead code afterward.
Bug: T336004
Change-Id: Ie7c50a6efe7a0aefc97a712b2ad961e7837cc4cf
Details in Ia4df6350f849ca27.
The global variable will still work in most cases, but the way it was
used here (as wgExtensionFunctions callback) will stop working to
allow MW core to run plain `phpunit` (T90875).
Migrate to the MW_QUIBBLE_CI constant instead, which is set in all
the same circumstances
Change-Id: I25acee1e6e88ca745435cbfa0b398041f04c94d6
isBadLoginPerUserTriggered() can never return null. This comment was
added in 2016 in 31c59374a4 and it was
already incorrect then. I don't know where this idea came from.
Change-Id: Ib919999fe83562cb4fa80246ae7c6b4707da775c
This lays some groundwork for migrating from the main stash to a future
stash that resides in the primary datacenter.
Bug: T336004
Change-Id: I70ee88e9371af19890cb9e3da612d2bb7dc335e8
also fix the var name to match the one in the interface
Bug: T303433
Follow-Up: If48689fe068aa3ec56e51e01b84cf25c63bcbf0b
Change-Id: Ie47b98d08cba5217f8661aa44f6331447575d7ae
$wgWikimediaJenkinsCI may not be enabled in LocalSettings.php.
tests/phpunit/phpunit.php reads this global, but vendor/bin/phpunit does
not.
Bug: T90875
Change-Id: I91628f0e63d4f67d1d3060cca3a17b95e0faf826
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
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
