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
Found usage of isset() on expression $this->captchaSolved that appears
to be always set. isset() should only be used to suppress errors. Check
whether the expression is null instead.
See https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#isset
Change-Id: I5520786060b2aa2fca81acd40924d84e94e8dff2
We are getting rid of the schema of implementing this interface and
calling self::READ_* constants, it's confusing, inconsistent, prone to
clashes and isn't really useful for non-ORM systems (which we are not)
Bug: T354194
Change-Id: I03c893130aea133c7df3b1e81213f0cf9191ae3e
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
Status now provides declared $statusData property for holding
arbitrary data that can be used instead.
Bug: T326479
Depends-On: Ibe3f1f8b81bcfcb18551d3ca4cda464e4bdbcbce
Change-Id: I1342a8a8ca64b4040ed2b2d101d4574aedd888af
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 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
Use CacheKeyHelper to collect status of captchas that was activated instead of set random properties on page object.
Bug: T275710
Change-Id: I7942ccd6b58584f436f872bf7c9deb63ab84482a
This just won't work:
- For edits via the UI, errors are wrapped in an errorbox div by
EditPage.php, so this code is outputting an errorbox inside an
errorbox, which is simply painful to see.
- API edits don't format errors via HTML, so trying to pass raw HTML
there results in broken formatting
Bug: T293818
Change-Id: Ib74d128cc71246c7cfa72456cbe453e8086f2d63
* Avoid double-escaping the captcha-edit-fail message
via both Html::element and RawMessage.
* Also add suppress comment due to overall taint of
RawMessage.
Bug: T293818
Change-Id: I6b985266a26f6b152bca05a91f6054ed1a5f2a5a
ParserOptions::__construct() and Parser::preSaveTransform() both
accept an UserIdentity and don't need a full user object.
Bug: T289731
Change-Id: I9e3d3f21452167ae1b1e9dca664605ee471f90e2
ContentHandler::getContentText() is deprecated and should be
replaced with Content::getText() for TextContent instances.
Change-Id: Iafe14100b3776510c5159657f42f6c0c8d551539
Remove using of User::getCanonicalName since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T275030
Change-Id: Ic11a4259271c8941225882ddce64b53d44280409
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.PropertyDocumentation.MissingDocumentationPrivate
* MediaWiki.Commenting.PropertyDocumentation.MissingDocumentationProtected
* MediaWiki.Commenting.PropertyDocumentation.WrongStyle
Change-Id: I8479cfb5fbc67a6472e28045ece5ea2ae1ba6ac6
Changes:
* Do not return anything in a method that is not expected to return
something.
* Inline some previously hard to read code.
* More specific type hints, if possible.
Change-Id: I0e460899eea07d8733f638a11133adc3000f0542
