Follow up Ie956fe86184535a376d0398483ac3c853fa9127c
Make SimpleCaptcha::shouldCheck public since it is
called by Flow/includes/SpamFilter/ConfirmEdit.php(35)
and is now failing in production.
Bug: T199811
Change-Id: I85a813aaa06b896266c320089e24ca2e5e81d0ee
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
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
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPublic
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.MissingReturnType
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
* MediaWiki.Commenting.FunctionComment.WrongStyle
* MediaWiki.Files.ClassMatchesFilename.NotMatch
* MediaWiki.Files.OneClassPerFile.MultipleFound
The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment
Change-Id: Id3af93f7485712b063b758cbd40752c1bfcb0b2e
Follows-up 37f2dcf. confirmEditSetup() maps it to the new name so any use of it within
the extension can safely be replaced.
* Fix Catpcha.php.
* Update README.md.
Change-Id: I4b23954eba2d7d3e86e4f60d8189e263b864fbd3
* Move globals definition to the top of the function
* no else needed, if the if part returns always returns something
I came across this while reading the code in I3a56e4252bbb810c1cf5c632ece9a8edf91c8424
Change-Id: I826a41457667e886b65a07d9d9edc5daec7d1013
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I065808a2c4dc9bcb80861a79b46cf4b446b70d65
'type' is problematic as it conflicts with a default field name
in logstash.
Bug: T145133
Change-Id: Idb73ba3e431ef2bd25b14c8562d1b3f212b4e072
Depends-On: Iab1eb47a6b6c98f3c84b4f8e2d16cbe2cdbf515b
Since this extension uses extension.json, it already requires 1.25+ so
no need to keep the old code around.
Change-Id: I31b96b0939d5321be31889422cfc703c9c6c2baa
This commit removes SimpleCaptcha::getForm() and replaces it by its more informative
counterpart getFormInformation(), which returns an array, which provides some
more information about the form than only the html.
The information included in the array is:
* html: The HTML of the CAPTCHA form (this is the same as what you expected from
getForm() previously)
* modules: ResourceLoader modules, if any, that should be added to the output of the
page
* modulestyles: ResourceLoader style modules, if any, that should be added to th
output of the page
* headitems: Head items that should be added to the output (see OutputPage::addHeadItems)
Mostly you shouldn't need to handle the response of getFormInformation() anymore, as there's
a new function, addFormToOutput(), which takes an instance of OutputPage as a first parameter
and handles the response of getFormInformation for you (adds all information to the given
OutputPage instance, if they're provided).
Bug: T141300
Depends-On: I433afd124b57526caa13a540cda48ba2b99a9bde
Change-Id: I25f344538052fc18993c43185fbd97804a7cfc81
It was only needed for MediaWiki prior to 1.25
(09a5febb7b024c0b6585141bb05cba13a642f3eb).
We no longer support those versions after
1d08dd07b8.
Bug: T137832
Change-Id: I27f244631e9dcd160bffff70349e5034f2a537ea
passCaptcha was made protected in I0da671a546700110d789b79a3089460abd9cce3b,
but some other extensions used it, provide passCaptchaFromRequest as a
replacement.
Bug: T135477
Change-Id: I47b2e2fbe3e063cd86e8a2d6bc17ca939472dbe1
Also remove references to "two words" from ReCaptcha labels.
The captcha image doesn't always contain two words.
Bug: T110302
Change-Id: I544656289480056152a1db195babb6dadf29bc71
Also update MathCaptcha so that it works with recent versions of
Math (and breaks with old ones). Also fix MathCaptcha API output,
which used to send the question in plaintext.
Bug: T110302
Change-Id: I0da671a546700110d789b79a3089460abd9cce3b
Depends-On: I8b52ec8ddf494f23941807638f149f15b5e46b0c
Local administrators can now use [[MediaWiki:Captcha-ip-whitelist]]
page to exempt specific IP addresses and IP ranges from captchas.
This is useful for modifying in a short notice such as editathons and
other events like this where captchas add unnecessary complexity for
new users.
The page is disabled by default and IPs should be added separated by
newlines. If any other character is found on a line, it will be ignored
but leading and trailing whitespace characters are allowed.
Bug: T103122
Change-Id: I54866b5bfca80debcf3d3fb7963932ed03b48548
Use a default setting of > 20 logins in 10 minutes. In order to
achieve this many with core's default throttle's, you would have
to be attempting to login from at least 2 IP addresses.
Bug: T122164
Change-Id: Id3ea766cfb7d50444082275a628b8b2aa10e6050
If you are running multiple wikis, you probably want the rate limit
on one wiki to apply to all wikis
Bug: T126685
Change-Id: If5533f222eae9dc540b7c79606d7e7ce613f4e13
If the user has not resolved the "edit"-triggered CAPTCHA correctly,
show an error message, so the user knows, why their edit isn't saved.
Change-Id: Iecbf280e76e450d111f548fda29220688c65fc3a
The config needs to be an array to work, if any other type given it
will throw a warning, but doesn't show, that it will not work. Instead
of pass the edit as "not need to be checked", throw an exception to
indicate that something went wrong.
Change-Id: I4a2374ab2c5f8cf9ce5ea5f36f707a770a46a07d
Check, if an edit is being saved or not, before checking for captcha
triggers, that potentially could query the database or/and do other
expensive things.
Bug: T93961
Change-Id: Iab3e94e642c965becd23d31c6c1baa4c0cddacde
Logs a 'captcha.display' event when a captcha is displayed,
either via web or in an API response, and 'captcha.submit' when
a captcha response is evaluated.
Bug: T91701
Change-Id: I376fdd6740aca4f11776e1326ff2e7e6e5af6a75
Log exceeding the badcaptcha rate limit to the main captcha log (e.g.,
captcha.log on the WMF cluster).
So that we can measure the impact of things like
https://gerrit.wikimedia.org/r/#/c/195886/
Change-Id: I2af26d23b9343e90db2f01f099c1292914bd7ac3
