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
This doesn't work in PHP 7.2, because 'object' is no longer a valid
class name. stdClass works fine.
Change-Id: I47375fdf2f36ff62985b2e8c90fa0e5230273984
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
The captchas in production are registered conditional, in tests the
class needs to be added to the autoloader.
Moved this register up to setUp to detect the existing @covers correctly
by the new testValidCovers from
I1d564bcae2bfbedb004c440b90db6341148ed4ba
Change-Id: I79f225126d7bbbfd436ab165bb98a0ed9517b8bc
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
