wiki.techinc.nl/tests/phpunit/includes/BlockTest.php

454 lines
12 KiB
PHP
Raw Normal View History

2010-12-28 19:12:27 +00:00
<?php
/**
* @group Database
* @group Blocking
*/
2011-06-14 21:27:07 +00:00
class BlockTest extends MediaWikiLangTestCase {
/**
* @return User
*/
private function getUserForBlocking() {
$testUser = $this->getMutableTestUser();
$user = $testUser->getUser();
$user->addToDatabase();
TestUser::setPasswordForUser( $user, 'UTBlockeePassword' );
$user->saveSettings();
return $user;
}
/**
* @param User $user
*
* @return Block
* @throws MWException
*/
private function addBlockForUser( User $user ) {
// Delete the last round's block if it's still there
$oldBlock = Block::newFromTarget( $user->getName() );
if ( $oldBlock ) {
// An old block will prevent our new one from saving.
$oldBlock->delete();
}
$blockOptions = [
'address' => $user->getName(),
'user' => $user->getId(),
'reason' => 'Parce que',
'expiry' => time() + 100500,
];
$block = new Block( $blockOptions );
2010-12-28 19:12:27 +00:00
$block->insert();
// save up ID for use in assertion. Since ID is an autoincrement,
// its value might change depending on the order the tests are run.
// ApiBlockTest insert its own blocks!
if ( !$block->getId() ) {
throw new MWException( "Failed to insert block for BlockTest; old leftover block remaining?" );
}
$this->addXffBlocks();
return $block;
}
/**
* @covers Block::newFromTarget
*/
public function testINewFromTargetReturnsCorrectBlock() {
$user = $this->getUserForBlocking();
$block = $this->addBlockForUser( $user );
$this->assertTrue(
$block->equals( Block::newFromTarget( $user->getName() ) ),
"newFromTarget() returns the same block as the one that was made"
);
}
/**
* @covers Block::newFromID
*/
public function testINewFromIDReturnsCorrectBlock() {
$user = $this->getUserForBlocking();
$block = $this->addBlockForUser( $user );
$this->assertTrue(
$block->equals( Block::newFromID( $block->getId() ) ),
"newFromID() returns the same block as the one that was made"
);
2010-12-28 19:12:27 +00:00
}
2011-06-26 20:04:38 +00:00
/**
* per T28425
*/
public function testBug26425BlockTimestampDefaultsToTime() {
$user = $this->getUserForBlocking();
$block = $this->addBlockForUser( $user );
$madeAt = wfTimestamp( TS_MW );
// delta to stop one-off errors when things happen to go over a second mark.
$delta = abs( $madeAt - $block->mTimestamp );
$this->assertLessThan(
2,
$delta,
"If no timestamp is specified, the block is recorded as time()"
);
}
2010-12-28 19:12:27 +00:00
/**
* CheckUser since being changed to use Block::newFromTarget started failing
* because the new function didn't accept empty strings like Block::load()
* had. Regression T31116.
*
Clean and repair many phpunit tests (+ fix implied configuration) This commit depends on the introduction of MediaWikiTestCase::setMwGlobals in change Iccf6ea81f4. Various tests already set their globals, but forgot to restore them afterwards, or forgot to call the parent setUp, tearDown... Either way they won't have to anymore with setMwGlobals. Consistent use of function characteristics: * protected function setUp * protected function tearDown * public static function (provide..) (Matching the function signature with PHPUnit/Framework/TestCase.php) Replaces: * public function (setUp|tearDown)\( * protected function $1( * \tfunction (setUp|tearDown)\( * \tprotected function $1( * \tfunction (data|provide)\( * \tpublic static function $1\( Also renamed a few "data#", "provider#" and "provides#" functions to "provide#" for consistency. This also removes confusion where the /media tests had a few private methods called dataFile(), which were sometimes expected to be data providers. Fixes: TimestampTest often failed due to a previous test setting a different language (it tests "1 hour ago" so need to make sure it is set to English). MWNamespaceTest became a lot cleaner now that it executes with a known context. Though the now-redundant code that was removed didn't work anyway because wgContentNamespaces isn't keyed by namespace id, it had them was values... FileBackendTest: * Fixed: "PHP Fatal: Using $this when not in object context" HttpTest * Added comment about: "PHP Fatal: Call to protected MWHttpRequest::__construct()" (too much unrelated code to fix in this commit) ExternalStoreTest * Add an assertTrue as well, without it the test is useless because regardless of whether wgExternalStores is true or false it only uses it if it is an array. Change-Id: I9d2b148e57bada64afeb7d5a99bec0e58f8e1561
2012-10-08 10:56:20 +00:00
* @dataProvider provideBug29116Data
* @covers Block::newFromTarget
*/
public function testBug29116NewFromTargetWithEmptyIp( $vagueTarget ) {
$user = $this->getUserForBlocking();
$initialBlock = $this->addBlockForUser( $user );
$block = Block::newFromTarget( $user->getName(), $vagueTarget );
$this->assertTrue(
$initialBlock->equals( $block ),
"newFromTarget() returns the same block as the one that was made when "
. "given empty vagueTarget param " . var_export( $vagueTarget, true )
);
}
Clean and repair many phpunit tests (+ fix implied configuration) This commit depends on the introduction of MediaWikiTestCase::setMwGlobals in change Iccf6ea81f4. Various tests already set their globals, but forgot to restore them afterwards, or forgot to call the parent setUp, tearDown... Either way they won't have to anymore with setMwGlobals. Consistent use of function characteristics: * protected function setUp * protected function tearDown * public static function (provide..) (Matching the function signature with PHPUnit/Framework/TestCase.php) Replaces: * public function (setUp|tearDown)\( * protected function $1( * \tfunction (setUp|tearDown)\( * \tprotected function $1( * \tfunction (data|provide)\( * \tpublic static function $1\( Also renamed a few "data#", "provider#" and "provides#" functions to "provide#" for consistency. This also removes confusion where the /media tests had a few private methods called dataFile(), which were sometimes expected to be data providers. Fixes: TimestampTest often failed due to a previous test setting a different language (it tests "1 hour ago" so need to make sure it is set to English). MWNamespaceTest became a lot cleaner now that it executes with a known context. Though the now-redundant code that was removed didn't work anyway because wgContentNamespaces isn't keyed by namespace id, it had them was values... FileBackendTest: * Fixed: "PHP Fatal: Using $this when not in object context" HttpTest * Added comment about: "PHP Fatal: Call to protected MWHttpRequest::__construct()" (too much unrelated code to fix in this commit) ExternalStoreTest * Add an assertTrue as well, without it the test is useless because regardless of whether wgExternalStores is true or false it only uses it if it is an array. Change-Id: I9d2b148e57bada64afeb7d5a99bec0e58f8e1561
2012-10-08 10:56:20 +00:00
public static function provideBug29116Data() {
return [
[ null ],
[ '' ],
[ false ]
];
}
/**
* @covers Block::prevents
*/
public function testBlockedUserCanNotCreateAccount() {
$username = 'BlockedUserToCreateAccountWith';
$u = User::newFromName( $username );
$u->addToDatabase();
$userId = $u->getId();
$this->assertNotEquals( 0, $userId, 'sanity' );
TestUser::setPasswordForUser( $u, 'NotRandomPass' );
unset( $u );
// Sanity check
$this->assertNull(
Block::newFromTarget( $username ),
"$username should not be blocked"
);
// Reload user
$u = User::newFromName( $username );
$this->assertFalse(
$u->isBlockedFromCreateAccount(),
"Our sandbox user should be able to create account before being blocked"
);
// Foreign perspective (blockee not on current wiki)...
$blockOptions = [
'address' => $username,
'user' => $userId,
'reason' => 'crosswiki block...',
'timestamp' => wfTimestampNow(),
'expiry' => $this->db->getInfinity(),
'createAccount' => true,
'enableAutoblock' => true,
'hideName' => true,
'blockEmail' => true,
Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames Importing revisions in MediaWiki has long been weird: if the username on the imported revision exists locally it's automatically attributed to the local user, while if the name does not exist locally we wind up with revision table rows with rev_user = 0 and rev_user_text being a valid name that someone might later create. "Global" blocks too create rows with ipb_by = 0 an ipb_by_text being a valid name. The upcoming actor table change, as things currently stand, would regularize that a bit by automatically attributing those imported revisions to the newly-created user. But that's not necessarily what we actually want to happen. And it would certainly confuse CentralAuth's attempt to detect its own global blocks. Thus, this patch introduces "interwiki" usernames that aren't valid for local use, of the format "iw>Example".[1] Linker will interpret these names and generate an appropriate interwiki link in history pages and the like, as if from wikitext like `[[iw:User:Example]]`. Imports for non-existant local users (and optionally for existing local users too) will credit the edit to such an interwiki name. There is also a new hook, 'ImportHandleUnknownUser', to allow extension such as CentralAuth to create local users as their edits are imported. Block will no longer accept usable-but-nonexistent names for 'byText' or ->setBlocker(). CentralAuth's global blocks will be submitted with an interwiki username (see Ieae5d24f9). Wikis that have imported edits or CentralAuth global blocks should run the new maintenance/cleanupUsersWithNoId.php maintenance script. This isn't done by update.php because (1) it needs an interwiki prefix to use and (2) the updater can't know whether to pass the `--assign` flag. [1]: '>' was used instead of the more usual ':' because WMF wikis have many existing usernames containing colons. Bug: T9240 Bug: T20209 Bug: T111605 Change-Id: I5401941c06102e8faa813910519d55482dff36cb Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
2017-10-25 19:26:53 +00:00
'byText' => 'm>MetaWikiUser',
];
$block = new Block( $blockOptions );
$block->insert();
// Reload block from DB
$userBlock = Block::newFromTarget( $username );
$this->assertTrue(
(bool)$block->prevents( 'createaccount' ),
"Block object in DB should prevents 'createaccount'"
);
$this->assertInstanceOf(
'Block',
$userBlock,
"'$username' block block object should be existent"
);
// Reload user
$u = User::newFromName( $username );
$this->assertTrue(
(bool)$u->isBlockedFromCreateAccount(),
"Our sandbox user '$username' should NOT be able to create account"
);
}
/**
* @covers Block::insert
*/
public function testCrappyCrossWikiBlocks() {
// Delete the last round's block if it's still there
$oldBlock = Block::newFromTarget( 'UserOnForeignWiki' );
if ( $oldBlock ) {
// An old block will prevent our new one from saving.
$oldBlock->delete();
}
// Local perspective (blockee on current wiki)...
$user = User::newFromName( 'UserOnForeignWiki' );
$user->addToDatabase();
$userId = $user->getId();
$this->assertNotEquals( 0, $userId, 'sanity' );
// Foreign perspective (blockee not on current wiki)...
$blockOptions = [
'address' => 'UserOnForeignWiki',
'user' => $user->getId(),
'reason' => 'crosswiki block...',
'timestamp' => wfTimestampNow(),
'expiry' => $this->db->getInfinity(),
'createAccount' => true,
'enableAutoblock' => true,
'hideName' => true,
'blockEmail' => true,
Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames Importing revisions in MediaWiki has long been weird: if the username on the imported revision exists locally it's automatically attributed to the local user, while if the name does not exist locally we wind up with revision table rows with rev_user = 0 and rev_user_text being a valid name that someone might later create. "Global" blocks too create rows with ipb_by = 0 an ipb_by_text being a valid name. The upcoming actor table change, as things currently stand, would regularize that a bit by automatically attributing those imported revisions to the newly-created user. But that's not necessarily what we actually want to happen. And it would certainly confuse CentralAuth's attempt to detect its own global blocks. Thus, this patch introduces "interwiki" usernames that aren't valid for local use, of the format "iw>Example".[1] Linker will interpret these names and generate an appropriate interwiki link in history pages and the like, as if from wikitext like `[[iw:User:Example]]`. Imports for non-existant local users (and optionally for existing local users too) will credit the edit to such an interwiki name. There is also a new hook, 'ImportHandleUnknownUser', to allow extension such as CentralAuth to create local users as their edits are imported. Block will no longer accept usable-but-nonexistent names for 'byText' or ->setBlocker(). CentralAuth's global blocks will be submitted with an interwiki username (see Ieae5d24f9). Wikis that have imported edits or CentralAuth global blocks should run the new maintenance/cleanupUsersWithNoId.php maintenance script. This isn't done by update.php because (1) it needs an interwiki prefix to use and (2) the updater can't know whether to pass the `--assign` flag. [1]: '>' was used instead of the more usual ':' because WMF wikis have many existing usernames containing colons. Bug: T9240 Bug: T20209 Bug: T111605 Change-Id: I5401941c06102e8faa813910519d55482dff36cb Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
2017-10-25 19:26:53 +00:00
'byText' => 'Meta>MetaWikiUser',
];
$block = new Block( $blockOptions );
$res = $block->insert( $this->db );
$this->assertTrue( (bool)$res['id'], 'Block succeeded' );
$user = null; // clear
$block = Block::newFromID( $res['id'] );
$this->assertEquals(
'UserOnForeignWiki',
$block->getTarget()->getName(),
'Correct blockee name'
);
$this->assertEquals( $userId, $block->getTarget()->getId(), 'Correct blockee id' );
Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames Importing revisions in MediaWiki has long been weird: if the username on the imported revision exists locally it's automatically attributed to the local user, while if the name does not exist locally we wind up with revision table rows with rev_user = 0 and rev_user_text being a valid name that someone might later create. "Global" blocks too create rows with ipb_by = 0 an ipb_by_text being a valid name. The upcoming actor table change, as things currently stand, would regularize that a bit by automatically attributing those imported revisions to the newly-created user. But that's not necessarily what we actually want to happen. And it would certainly confuse CentralAuth's attempt to detect its own global blocks. Thus, this patch introduces "interwiki" usernames that aren't valid for local use, of the format "iw>Example".[1] Linker will interpret these names and generate an appropriate interwiki link in history pages and the like, as if from wikitext like `[[iw:User:Example]]`. Imports for non-existant local users (and optionally for existing local users too) will credit the edit to such an interwiki name. There is also a new hook, 'ImportHandleUnknownUser', to allow extension such as CentralAuth to create local users as their edits are imported. Block will no longer accept usable-but-nonexistent names for 'byText' or ->setBlocker(). CentralAuth's global blocks will be submitted with an interwiki username (see Ieae5d24f9). Wikis that have imported edits or CentralAuth global blocks should run the new maintenance/cleanupUsersWithNoId.php maintenance script. This isn't done by update.php because (1) it needs an interwiki prefix to use and (2) the updater can't know whether to pass the `--assign` flag. [1]: '>' was used instead of the more usual ':' because WMF wikis have many existing usernames containing colons. Bug: T9240 Bug: T20209 Bug: T111605 Change-Id: I5401941c06102e8faa813910519d55482dff36cb Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
2017-10-25 19:26:53 +00:00
$this->assertEquals( 'Meta>MetaWikiUser', $block->getBlocker()->getName(),
'Correct blocker name' );
$this->assertEquals( 'Meta>MetaWikiUser', $block->getByName(), 'Correct blocker name' );
$this->assertEquals( 0, $block->getBy(), 'Correct blocker id' );
}
protected function addXffBlocks() {
static $inited = false;
if ( $inited ) {
return;
}
$inited = true;
$blockList = [
[ 'target' => '70.2.0.0/16',
'type' => Block::TYPE_RANGE,
'desc' => 'Range Hardblock',
'ACDisable' => false,
'isHardblock' => true,
'isAutoBlocking' => false,
],
[ 'target' => '2001:4860:4001::/48',
'type' => Block::TYPE_RANGE,
'desc' => 'Range6 Hardblock',
'ACDisable' => false,
'isHardblock' => true,
'isAutoBlocking' => false,
],
[ 'target' => '60.2.0.0/16',
'type' => Block::TYPE_RANGE,
'desc' => 'Range Softblock with AC Disabled',
'ACDisable' => true,
'isHardblock' => false,
'isAutoBlocking' => false,
],
[ 'target' => '50.2.0.0/16',
'type' => Block::TYPE_RANGE,
'desc' => 'Range Softblock',
'ACDisable' => false,
'isHardblock' => false,
'isAutoBlocking' => false,
],
[ 'target' => '50.1.1.1',
'type' => Block::TYPE_IP,
'desc' => 'Exact Softblock',
'ACDisable' => false,
'isHardblock' => false,
'isAutoBlocking' => false,
],
];
Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames Importing revisions in MediaWiki has long been weird: if the username on the imported revision exists locally it's automatically attributed to the local user, while if the name does not exist locally we wind up with revision table rows with rev_user = 0 and rev_user_text being a valid name that someone might later create. "Global" blocks too create rows with ipb_by = 0 an ipb_by_text being a valid name. The upcoming actor table change, as things currently stand, would regularize that a bit by automatically attributing those imported revisions to the newly-created user. But that's not necessarily what we actually want to happen. And it would certainly confuse CentralAuth's attempt to detect its own global blocks. Thus, this patch introduces "interwiki" usernames that aren't valid for local use, of the format "iw>Example".[1] Linker will interpret these names and generate an appropriate interwiki link in history pages and the like, as if from wikitext like `[[iw:User:Example]]`. Imports for non-existant local users (and optionally for existing local users too) will credit the edit to such an interwiki name. There is also a new hook, 'ImportHandleUnknownUser', to allow extension such as CentralAuth to create local users as their edits are imported. Block will no longer accept usable-but-nonexistent names for 'byText' or ->setBlocker(). CentralAuth's global blocks will be submitted with an interwiki username (see Ieae5d24f9). Wikis that have imported edits or CentralAuth global blocks should run the new maintenance/cleanupUsersWithNoId.php maintenance script. This isn't done by update.php because (1) it needs an interwiki prefix to use and (2) the updater can't know whether to pass the `--assign` flag. [1]: '>' was used instead of the more usual ':' because WMF wikis have many existing usernames containing colons. Bug: T9240 Bug: T20209 Bug: T111605 Change-Id: I5401941c06102e8faa813910519d55482dff36cb Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
2017-10-25 19:26:53 +00:00
$blocker = $this->getTestUser()->getUser();
foreach ( $blockList as $insBlock ) {
$target = $insBlock['target'];
if ( $insBlock['type'] === Block::TYPE_IP ) {
$target = User::newFromName( IP::sanitizeIP( $target ), false )->getName();
} elseif ( $insBlock['type'] === Block::TYPE_RANGE ) {
$target = IP::sanitizeRange( $target );
}
$block = new Block();
$block->setTarget( $target );
Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames Importing revisions in MediaWiki has long been weird: if the username on the imported revision exists locally it's automatically attributed to the local user, while if the name does not exist locally we wind up with revision table rows with rev_user = 0 and rev_user_text being a valid name that someone might later create. "Global" blocks too create rows with ipb_by = 0 an ipb_by_text being a valid name. The upcoming actor table change, as things currently stand, would regularize that a bit by automatically attributing those imported revisions to the newly-created user. But that's not necessarily what we actually want to happen. And it would certainly confuse CentralAuth's attempt to detect its own global blocks. Thus, this patch introduces "interwiki" usernames that aren't valid for local use, of the format "iw>Example".[1] Linker will interpret these names and generate an appropriate interwiki link in history pages and the like, as if from wikitext like `[[iw:User:Example]]`. Imports for non-existant local users (and optionally for existing local users too) will credit the edit to such an interwiki name. There is also a new hook, 'ImportHandleUnknownUser', to allow extension such as CentralAuth to create local users as their edits are imported. Block will no longer accept usable-but-nonexistent names for 'byText' or ->setBlocker(). CentralAuth's global blocks will be submitted with an interwiki username (see Ieae5d24f9). Wikis that have imported edits or CentralAuth global blocks should run the new maintenance/cleanupUsersWithNoId.php maintenance script. This isn't done by update.php because (1) it needs an interwiki prefix to use and (2) the updater can't know whether to pass the `--assign` flag. [1]: '>' was used instead of the more usual ':' because WMF wikis have many existing usernames containing colons. Bug: T9240 Bug: T20209 Bug: T111605 Change-Id: I5401941c06102e8faa813910519d55482dff36cb Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
2017-10-25 19:26:53 +00:00
$block->setBlocker( $blocker );
$block->mReason = $insBlock['desc'];
$block->mExpiry = 'infinity';
$block->prevents( 'createaccount', $insBlock['ACDisable'] );
$block->isHardblock( $insBlock['isHardblock'] );
$block->isAutoblocking( $insBlock['isAutoBlocking'] );
$block->insert();
}
}
public static function providerXff() {
return [
[ 'xff' => '1.2.3.4, 70.2.1.1, 60.2.1.1, 2.3.4.5',
'count' => 2,
'result' => 'Range Hardblock'
],
[ 'xff' => '1.2.3.4, 50.2.1.1, 60.2.1.1, 2.3.4.5',
'count' => 2,
'result' => 'Range Softblock with AC Disabled'
],
[ 'xff' => '1.2.3.4, 70.2.1.1, 50.1.1.1, 2.3.4.5',
'count' => 2,
'result' => 'Exact Softblock'
],
[ 'xff' => '1.2.3.4, 70.2.1.1, 50.2.1.1, 50.1.1.1, 2.3.4.5',
'count' => 3,
'result' => 'Exact Softblock'
],
[ 'xff' => '1.2.3.4, 70.2.1.1, 50.2.1.1, 2.3.4.5',
'count' => 2,
'result' => 'Range Hardblock'
],
[ 'xff' => '1.2.3.4, 70.2.1.1, 60.2.1.1, 2.3.4.5',
'count' => 2,
'result' => 'Range Hardblock'
],
[ 'xff' => '50.2.1.1, 60.2.1.1, 2.3.4.5',
'count' => 2,
'result' => 'Range Softblock with AC Disabled'
],
[ 'xff' => '1.2.3.4, 50.1.1.1, 60.2.1.1, 2.3.4.5',
'count' => 2,
'result' => 'Exact Softblock'
],
[ 'xff' => '1.2.3.4, <$A_BUNCH-OF{INVALID}TEXT\>, 60.2.1.1, 2.3.4.5',
'count' => 1,
'result' => 'Range Softblock with AC Disabled'
],
[ 'xff' => '1.2.3.4, 50.2.1.1, 2001:4860:4001:802::1003, 2.3.4.5',
'count' => 2,
'result' => 'Range6 Hardblock'
],
];
}
/**
* @dataProvider providerXff
* @covers Block::getBlocksForIPList
* @covers Block::chooseBlock
*/
public function testBlocksOnXff( $xff, $exCount, $exResult ) {
$user = $this->getUserForBlocking();
$this->addBlockForUser( $user );
$list = array_map( 'trim', explode( ',', $xff ) );
$xffblocks = Block::getBlocksForIPList( $list, true );
$this->assertEquals( $exCount, count( $xffblocks ), 'Number of blocks for ' . $xff );
$block = Block::chooseBlock( $xffblocks, $list );
$this->assertEquals( $exResult, $block->mReason, 'Correct block type for XFF header ' . $xff );
}
public function testDeprecatedConstructor() {
$this->hideDeprecated( 'Block::__construct with multiple arguments' );
$username = 'UnthinkablySecretRandomUsername';
$reason = 'being irrational';
# Set up the target
$u = User::newFromName( $username );
if ( $u->getId() == 0 ) {
$u->addToDatabase();
TestUser::setPasswordForUser( $u, 'TotallyObvious' );
}
unset( $u );
# Make sure the user isn't blocked
$this->assertNull(
Block::newFromTarget( $username ),
"$username should not be blocked"
);
# Perform the block
$block = new Block(
/* address */ $username,
/* user */ 0,
/* by */ 0,
/* reason */ $reason,
/* timestamp */ 0,
/* auto */ false,
/* expiry */ 0
);
$block->insert();
# Check target
$this->assertEquals(
$block->getTarget()->getName(),
$username,
"Target should be set properly"
);
# Check supplied parameter
$this->assertEquals(
$block->mReason,
$reason,
"Reason should be non-default"
);
# Check default parameter
$this->assertFalse(
(bool)$block->prevents( 'createaccount' ),
"Account creation should not be blocked by default"
);
}
public function testSystemBlocks() {
$user = $this->getUserForBlocking();
$this->addBlockForUser( $user );
$blockOptions = [
'address' => $user->getName(),
'reason' => 'test system block',
'timestamp' => wfTimestampNow(),
'expiry' => $this->db->getInfinity(),
Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames Importing revisions in MediaWiki has long been weird: if the username on the imported revision exists locally it's automatically attributed to the local user, while if the name does not exist locally we wind up with revision table rows with rev_user = 0 and rev_user_text being a valid name that someone might later create. "Global" blocks too create rows with ipb_by = 0 an ipb_by_text being a valid name. The upcoming actor table change, as things currently stand, would regularize that a bit by automatically attributing those imported revisions to the newly-created user. But that's not necessarily what we actually want to happen. And it would certainly confuse CentralAuth's attempt to detect its own global blocks. Thus, this patch introduces "interwiki" usernames that aren't valid for local use, of the format "iw>Example".[1] Linker will interpret these names and generate an appropriate interwiki link in history pages and the like, as if from wikitext like `[[iw:User:Example]]`. Imports for non-existant local users (and optionally for existing local users too) will credit the edit to such an interwiki name. There is also a new hook, 'ImportHandleUnknownUser', to allow extension such as CentralAuth to create local users as their edits are imported. Block will no longer accept usable-but-nonexistent names for 'byText' or ->setBlocker(). CentralAuth's global blocks will be submitted with an interwiki username (see Ieae5d24f9). Wikis that have imported edits or CentralAuth global blocks should run the new maintenance/cleanupUsersWithNoId.php maintenance script. This isn't done by update.php because (1) it needs an interwiki prefix to use and (2) the updater can't know whether to pass the `--assign` flag. [1]: '>' was used instead of the more usual ':' because WMF wikis have many existing usernames containing colons. Bug: T9240 Bug: T20209 Bug: T111605 Change-Id: I5401941c06102e8faa813910519d55482dff36cb Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
2017-10-25 19:26:53 +00:00
'byText' => 'MediaWiki default',
'systemBlock' => 'test',
'enableAutoblock' => true,
];
$block = new Block( $blockOptions );
$this->assertSame( 'test', $block->getSystemBlockType() );
try {
$block->insert();
$this->fail( 'Expected exception not thrown' );
} catch ( MWException $ex ) {
$this->assertSame( 'Cannot insert a system block into the database', $ex->getMessage() );
}
try {
$block->doAutoblock( '192.0.2.2' );
$this->fail( 'Expected exception not thrown' );
} catch ( MWException $ex ) {
$this->assertSame( 'Cannot autoblock from a system block', $ex->getMessage() );
}
}
2010-12-28 19:12:27 +00:00
}