Why:
- forceShowCaptcha is set if another extension wants to ensure that a
CAPTCHA is presented to the user. In this case, the 'captcha-edit'
message is more appropriate than 'captcha-edit-fail' as
'captcha-edit-fail' implies that the user already tried and failed to
solve the CAPTCHA.
What:
- Use 'captcha-edit' message on confirm edit hook failure if
'shouldForceShowCaptcha' is set
- ... but use 'captcha-edit-fail' if the user submitted an attempt.
Note that the updated message only works in the source editor,
not in VisualEditor or DiscussionTools
Depends-On: I5a0698d84932a474800a68dba9b76b3433b19290
Bug: T20110
Change-Id: Ie13181b78b8e2903c6cc0f0f778689bcc8b8ce2e
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
It does nothing, because the 'mediawiki.ui.input' module is not loaded
on the edit form, so it doesn't apply any styles.
I'm not sure if it ever worked, but it definitely hasn't worked since
at least 2021 (that's the oldest wiki I found on Patchdemo that has
the class but doesn't have the styling).
Change-Id: Ibd9d3df3aa74eb22c6b7fed97076056fc4187c66
