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
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
2019-06-13 22:56:31 +02:00
Renamed from tests/phpunit/includes/auth/AuthenticationResponseTest.php (Browse further)
