I find most uses of array_filter(), array_reduce(), etc. to be
excessively clever, i.e. they are used to prove how smart the
developer is, at the expense of readability and performance. So I am
pleased to have a defensible reason to remove these instances, which
broke PHPStorm's type propagation.
Change-Id: I03dcd6c3c80f19f90e7b39448b5508713da63806
This patch fixes all PHPUnit 8 compat issues in the DBless suite, aside
from assertArraySubset.
Bug: T192167
Change-Id: Iea782386509b9e579f06d63687669e14bc437fad
*assertType is marked as deprecated, and should ideally be removed soon
(i.e. no hard deprecation to follow)
*Most usages of assertType in core were autofixed by using I8ef556b630812aeea77c5606713f53d9af609f1b
*assertTypeOrValue was removed because only used in SiteTest
(codesearch: https://codesearch.wmflabs.org/search/?q=assertTypeOrValue&i=nope&files=&repos=)
*SiteTest::assertTypeOrFalse was removed because unused
Bug: T192167
Change-Id: Icb3014b8fe7d1c43e64a37e0bdaaffec18bb482f
Done automatically using the master version of MW codesniffer and
running composer fix.
Bug: T192167
Change-Id: If6b40f515fde32ab5eff074a90e821c30c791827
Before this, authentication error messages are custom built and do not
contain as much information as block error messages for other actions.
They also assume the block target is either an IP or an IP range, and
have no customisation for different types of block.
Instead, this uses the BlockErrorFormatter to choose the most
appropriate and informative message for the block.
Bug: T227110
Change-Id: I942ac605075b6c2174682c7e75fe1213f82ebea2
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
PHP doesn't care much but I think we humans do because we should
call methods by the name we give them. Method fixed are;
- isOk() -> isOK()
- setOk() -> setOK()
- teardown() -> tearDown()
Change-Id: I6b3f0cf3902887058efa426968da380803869e0b
Now that resetServices() will preserve (but reset) customized services,
it should be reasonably safe to call it every time globals are changed,
and much more effective than relying on tests to call it every time
themselves.
Depends-On: Iab8ea3a61bbc6803805d855ef23c071067646f71
Depends-On: I00e35ecea6a27468674b2a6e7d9d9eb6518e3bd5
Change-Id: Ie7a89f6ed7d52a0bc01672019ff92e7ee105a1f3
This changeset resumes work on T89432 and related tickets
by porting an initial set of tests to the new unit test suite
separated out in I69b92db3e70093570e05cc0a64c7780a278b321a.
The tests were only ported if they worked immediately without
requiring any changes other than changing the test case class
to MediaWikiUnitTestCase and moving the test to the new suite.
If a test failed for any reason (even trivial misconfiguration),
it was NOT ported.
With this change, the unit tests suite now consits of a total
of 455 tests. As before, you can run these tests via the following
command:
$ composer phpunit:unit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ibb8175981092d7f41864e641cc3c118af70a5c76
Was reverted by I549810a4cd2e424cc4a438887d2f24614a24cc00 due to
T224607.
Original change by Vedmaka Wakalaka was
Ia0d840b772ea5f20c9594ce151cc57adc270e48b.
Original commit message:
The following methods should are factored out of the User class into PermissionManager,
leaving only deprecated stubs:
- User::isAllowed -> PermissionManager::userHasRight
- User::getRights -> PermissionManager::getUserPermissions
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::getGroupPermissions -> PermissionManager::getGroupPermissions
-User::getGroupsWithPermission -> PermissionManager::getGroupsWithPermission
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::isEveryoneAllowed -> PermissionManager::isEveryoneAllowed
- User::getAllRights -> PermissionManager::getAllPermissions
Depends-On: I7909e9bd6bbfbd708c0a00b861a9b22a38c6665d
Bug: T218558
Bug: T223294
Change-Id: I8899240378f636ea70f447616710516c0a3c5c31
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
Keep Block as a deprecated class alias for DatabaseBlock.
Update calls to the Block constructor and Block static
methods from external classes.
Also update documentation in several places that refer to
blocks as Blocks.
Bug: T222737
Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
This global function was deprecated in 1.30 and is replaced with
the use of `ObjectCache::getLocalClusterInstance()->makeKey()`.
Change-Id: Ic08b53111be4374a973e08c2ed68224bfa922fa8
This introduces a minimal BlockManager service, for getting blocks
that apply to a User.
Move the part of User::getBlockedStatus that checks for the blocks
into BlockManager::getUserBlock, and move the related helper
methods from User to BlockManager.
Hard deprecate or remove these helper methods, and move to private
methods in the BlockManager:
* User::getBlockFromCookieValue
* User::isLocallyBlockedProxy
* User::inDnsBlacklist
Soft deprecate these helper methods, and move to public methods in
the BlockManager:
* User::isDnsBlacklisted
Add tests to cover the methods moved to BlockManager.
Bug: T219441
Change-Id: I0af658d71288376735cebe541215383b56bb72e5
HHVM does not support variadic arguments with type hints. This is
mostly not a big problem, because we can just drop the type hint, but
for some reason PHPUnit adds a type hint of "array" when it creates
mocks, so a class with a variadic method can't be mocked (at least in
some cases). As such, I left alone all the classes that seem like
someone might like to mock them, like Title and User. If anyone wants
to mock them in the future, they'll have to switch back to
func_get_args(). Some of the changes are definitely safe, like
functions and test classes.
In most cases, func_get_args() (and/or func_get_arg(), func_num_args() )
were only present because the code was written before we required PHP
5.6, and writing them as variadic functions is strictly superior. In
some cases I left them alone, aside from HHVM compatibility:
* Forwarding all arguments to another function. It's useful to keep
func_get_args() here where we want to keep the list of expected
arguments and their meanings in the function signature line for
documentation purposes, but don't want to copy-paste a long line of
argument names.
* Handling deprecated calling conventions.
* One or two miscellaneous cases where we're basically using the
arguments individually but want to use them as an array as well for
some reason.
Change-Id: I066ec95a7beb7c0665146195a08e7cce1222c788
$wgUser is not guaranteed to exist until MediaWiki has been fully
initialized; block status needs to be checked early on for
authentication-related permission checks.
Bug: T218608
Change-Id: I16315c071855024bc0412d5360c95f843420d9a9
Password policy checks that fail and have `suggestChangeOnLogin` set to true will
prompt for a password change on login.
Below are some rules that apply to this setting in different scenarios:
- If only one policy fails and has `suggestChangeOnLogin = false`, a password change will
not be requested
- If more than one policy fails and one or more have `suggestChangeOnLogin` set to true`,
a password change will be requested
- If `forceChange` is present in any of the failing policies, `suggestChangeOnLogin` value
will be ignored and password change will be enforced
- if $wgInvalidPasswordReset is set to false `suggestChangeOnLogin` is ignored
IMPORTANT**
Before this patch, suggesting a password change was the default behavior (depending on
$wgInvalidPasswordReset), which means that the necessary changes to $wgPasswordPolicy
need to be in place before this patch is merged and gets to production.
Bug: T211621
Change-Id: I7a4a0a06273fa4e8bd0da3dac54cf5a1b78bb3fd
AuthManager::autoCreateUser() causes createAndPromote.php to give error
"Automatic account creation is not allowed." when
$wgGroupPermissions['*']['createaccount']=false is set. Anonymous user
checks should be skipped for maintenance scripts.
Change-Id: Ib61889a758e542abe991707d8b7853a25cfed8e9
Adds a way to set an array of options for a password policy. Currently
there is one option, 'forceChange', which forces the user to change
their password (if it fails the given check) before logging in.
Bug: T118774
Change-Id: I28c31fc4eae08c3ac44eff3a05f5e785ce4b9e01
Updated unit tests as well for AuthManagerTest::testContinueAccountCreation()
and AuthManagerTest::testContinueAccountLink().
Change-Id: I96363e34688517796c2812cb3f483e1bfa26be6b
The hooks that used to be called by this class will be removed in
I24d6fa963. The only reason to keep this class around is that
someone might have added it to $wgAuthManagerConfig so removing
it would trigger class lookup failures, so make sure any use
of the class triggers a deprecation warning.
Change-Id: I9755288eda7461ecf3dcd35de2081fbb3eb04ae3
This method encourages directly editing configuration variables. It's a
better idea to use setMwGlobals() (or other set wrappers) so that we can
be intelligent in the future, for instance resetting services after the
config change. Plus, a lot of the callers come out cleaner this way
anyway.
Depends-On: I8a1e81acc5c42a8d7f30938a72cface0acea4a70
Depends-On: I4105dbcf9c5399fe7239478c460ec57c015a98d4
Depends-On: I1b220996acf2f66cf7b0f092b341584663df32f9
Depends-On: Ie2d1ea65c0cb334bbde1666d00781474b7ac4dab
Change-Id: I23d77398e401f4986b1d5bd1c9e11a8a40da16f8
Instead of having basically every caller do:
$pf = new PasswordFactory();
$pf->init( RequestContext::getMain()->getConfig() );
Just create a single PasswordFactory via MediaWikiServices and pass that
around. Things that want to use their own config can still pass settings
via the new constructor.
This will eventually let us remove the init() function, removing the
only hard dependency upon MediaWiki, to make it easier to librarize
(T89742).
Change-Id: I0fc7520dc023b11a7fa66083eff7b88ebfe49c7b
This avoids error-prone code written separately in every test. In
addition to no existing tests resetting the TitleFormatter (more
services probably need to be reset as well), they mostly reset only the
namespace cache on $wgContLang, which wouldn't help for any other
language.
The parser test runner still doesn't do this, but maybe it should.
Change-Id: I44b7a1aec48f14b0950907fa14bd0df80f674296
This changes behavior in some tests by making them set $wgLanguageCode
as well as $wgContLang, but that seems like a good thing.
Bug: T200246
Change-Id: I936888f46ff9fefe2707efba837e2ce3a7ca5e3f
