The method User::isBlocked() attempts to answer two questions:
(1) Does the user have a block?
(2) Is the user prevented from performing this action?
The method can answer #1, but it cannot answer #2. Since User::getBlock() can
also answer #1, this method is redundant. The method cannot answer #2 because
there is not enough context in order to answer that question.
If access is being checked against a Title object, all access checks can be
performed with PermissionManager:userCan() which will also check the user's
blocks.
If performing all access checks is not desirable, using
PermissionManager::isBlockedFrom() is also acceptable for only checking if the
user is blocked. This method does *not* determine if the action is allowed,
only that the user's block applies to that Title.
If access is being checked without an existing Title, User::getBlock() can be
used to get the user's block. Then Block::appliesToRight() can be used to
determine if the block applies explicitly to a right (or returns null if
it is unknown or false if explicitly allowed). If the user is creating a new
Title, but the text of the title is not yet known (as in the case of Wikibase),
access should be checked with Block::appliesToNamespace().
Bug: T209004
Change-Id: Ic0ad1b92e957797fee8dcd00bd1092fe69fa58f1
Use getters and setters for $mReason, $mTimestamp, $mExpiry and
$mHideName; use Block::getType to check if a block is an autoblock
instead of checking $mAuto; no change needed for $mParentBlockId,
which is not accessed externally.
Change-Id: I767ed44ce4c2e21f53962d75fb86891add2282f6
If a user being auto-created is blocked from account creation without a
reason given, CheckBlocksPrimaryAuthProvider is triggering a
"User::loadFromSession called before the end of Setup.php" log message
when trying to fill in a reason using 'blockednoreason'.
In this situation, use the content language instead.
Bug: T124367
Change-Id: Id94c919cdba5e4218b709ba8ac9d0fa17f0c3f8e
This will allow providers to know whether the call is just for testing
(from ApiQueryUsers) or for actual creation, and skip duplicate work
when testForAccountCreation() is going to be called.
Change-Id: Id3ef713fd377135d78f66e5100dedd4689293b59
Depends-On: I4af8b3b692f60c42f8685b90be5936da7ba4e2e2
Depends-On: Ie9639a15d04b387be0e72754301eb6d91cd8adc2
Depends-On: I063cbdfbd9a223bf2391fce2b714ab82ddd3272f
Depends-On: I7c67512634f6e72251911238f083857da9fd3f84
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.
Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
