Creation of dynamic property Mock_AuthenticationRequest_4d271de1::$done
is deprecated in php8.2
Bug: T314099
Change-Id: I21e7a257a5e695cc32f183add5ba6785a6898118
Allows AuthenticationResponse to store, when the status is FAIL,
an array of strings that describe the reasons for the failure.
These are stored in $failReasons and are not intended for the
client. On any other status $failReasons is null. These are
optionally provided when calling AuthenticationResponse::newFail
in the parameter $failReasons.
This is implemented to allow the CentralAuth extension to store
whether the password was correct if the account is locked inside
the AuthenticationResponse. The extension CheckUser which hooks
into authentication requests then can read the failure reasons
from the AuthenticationResponse, and can then note in the CU
entry that the login attempt had the correct password.
If whether the correct password was used is stored in the I18n
message, the client would then know if the password they tried
on the locked account was correct. For comprimised accounts this
could be used by mailicious actors to verify that the password
was correct and then try it elsewhere if the account has the same
password as on other sites. This means, unless I have missed
another method, a new array is needed to store these failure reasons.
This, along with some other patches to CheckUser and CentralAuth,
will then allow Checkusers to see if a login attempt for a locked
account had the correct password. Checkusers can then use this,
with the knowledge that the account isn't comprimised, to say that
the login attempt was made by the owner of the account so in cases
of socking the creation of a new account can be more conclusively
said to be by the person who created the now locked sock account.
Bug: T303192
Change-Id: I7b2d9579a518a6c02f05281b1016e31e0d086fe7
Create new AuthenticationProviderTestTrait and AuthenticationProviderTestTrait
::initProvider method. Replace uses of AbstractAuthenticationProvider::init with new method in
tests.
Bug: T282781
Change-Id: Ie65c7558bfbacbf6678eea77e4a9b2cf68026456
init() method was added to AuthenticationProvider. It helps to inject
dependecies. Overridable postInitSetup() method was added to
AbstractAuthenticationProvider. A provider can override this to do
any necessary setup.
AbstractAuthenticationProvider ::setLogger(), ::setManager(), ::setConfig(),
::setHookContainer() were soft deprecated. Now developers must use
AbstractAuthenticationProvider::init().
Bug: T275030
Change-Id: I6ca63eddac1b177eeadbdcce992e71c44a480160
It's the same and makes the test code much more readable, I
would like to argue.
Because of the was I split all the changes I made into smaller
patches this patch contains some other changes in the same
lines where I could not split them off. E.g. removal of
->any(), which is the default anyway and doesn't do anything.
Change-Id: Ib297b989d4aec33b31a4e33fe9d5032865b39be0
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
No integration is needed.
Additionally, change namespace to reflect that it's a test class
rather than normal code.
Change-Id: Iaa591310edde57de02c710ed1741388b4abafd01
No integration is needed.
Additionally, change namespace to reflect that it's a test class
rather than normal code.
Change-Id: Iaa05945805e3417ee149204b3e5b4085e6a06007
There is native support for all of this now in PHP, thanks to changes
and additions that have been made in later versions. There should be no
need any more to ever use call_user_func() or call_user_func_array().
Reviewing this should be fairly easy: Because this patch touches
exclusivly tests, but no production code, there is no such thing as
"insufficent test coverage". As long as CI goes green, this should be
fine.
Change-Id: Ib9690103687734bb5a85d3dab0e5642a07087bbc
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
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
