Block::prevents plays several different roles:
* acts as get/setter for Boolean properties that correspond to
ipb_create_account, ipb_block_email and ipb_allow_usertalk
* calculates whether a block blocks a given right, based on Block
properties, global configs, white/blacklists and anonymous user
rights
* decides whether a block prevents editing of the target's own
user talk page (listed separately because 'editownusertalk' is
not a right)
This patch:
* renames mDisableUsertalk to allowEditUsertalk (and reverses the
value), to match the field ipb_allow_usertalk and make this logic
easier to follow
* renames mCreateAccount to blockCreateAccount, to make it clear
that the flag blocks account creation when true, and make this
logic easier to follow
* decouples the block that is stored in the database (which now
reflects the form that the admin submitted) and the behaviour of
the block on enforcement (since the properties set by the admin
can be overridden by global configs) - so if the global configs
change, the block behaviour could too
* creates get/setters for blockCreateAccount, mBlockEmail and
allowEditUsertalk properties
* creates appliesToRight, exclusively for checking whether the
block blocks a given right, taking into account the block
properties, global configs and anonymous user rights
* creates appliesToUsertalk, for checking whether the block
blocks a user from editing their own talk page. The block is
unaware of the user trying to make the edit, and this user is not
always the same as the block target, e.g. if the block target is
an IP range. Therefore the user's talk page is passed in to this
method. appliesToUsertalk can be called from anywhere where the
user is known
* uses the get/setters wherever Block::prevents was being used as
such
* uses appliesToRight whenever Block::prevents was being used to
determine if the block blocks a given right
* uses appliesToUsertalk in User::isBlockedFrom
Bug: T211578
Bug: T214508
Change-Id: I0e131696419211319082cb454f4f05297e55d22e
The global config $wgBlockDisablesLogin can override certain block flags
if true, causing some tests to fail. Set it to false for these tests.
Change-Id: I497ef07bd34a1e458fd9692ef4874474e61151c8
There is a possibility that the retrieved action (by name) will not match the
passed in right, we should ensure that the retrieved action matches.
Also adds 'purge' to the whitelist of actions that are not prevented by a
block.
Bug: T213220
Change-Id: I5671dcd6f004b1663c8a5c5aec200abbf742ec1d
This begins work on making namespaces a valid restriction type. The CRUD
operations of BlockRestriction can now handle namespaces. Since
NamespaceRestriction implements Restriction, enforcement should start working
immediately, but testing enforcement will come in a subsequent patch since it's
impossible to create them.
Bug: T204991
Change-Id: I7264b452d9ad788c146d6ea25d01d4d7cb5ac4f6
The fix applied in d67121f6d took care of the immediate issue in
T208398, but after further analysis it was not a correct fix.
* Near line 770, the method shouldn't even be called unless the target
is TYPE_USER.
* Near line 1598, it isn't dealing with a target at all.
* Near line 1813, you're not going to get a sensible result trying to
call `$user->getTalkPage()` for a range or auto-block ID. What you
would really need there to handle range and auto-blocks correctly is
to pass in the User actually making the edit.
But after some pushback in code review about passing the User into
Block::preventsEdit() to make line 1813 work, we'll instead replace the
method with Block::appliesToTitle() and put the check for user talk
pages back into User::isBlockedFrom().
Bug: T208398
Bug: T208472
Change-Id: I23d3a3a1925e97f0cabe328c1cc74e978cb4d24a
Enforce partial blocks and display a slightly different block
notice depending on if the block is sitewide or not
Bug: T197117
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: I8a3635a4a04a33912eb139b7b13c4bd874183d31
Partial blocks logic will be used in multiple places. This
classes will group block restriction functionality to avoid
code duplication
Bug: T202036
Change-Id: I675316dddf272fd0d6172ecad3882160752bf780
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
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
Something is holding state and interfering with
RevisionUnitTest from within BlockTest
as seen in I4f24e7fbb683cb51f3fd8b250732bae9c7541ba2
PS30
Change-Id: I5b779941385eb88e560dd2c63a8aea356804c806
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
Blocks made for configured proxies, dnsbls, or the configured range
soft-blocks being added in I6c11a6b9 aren't real blocks stored in the
database. Let's actually flag these blocks as such and use a more
appropriate message when displaying them to the user.
Change-Id: I697e3eec2520792e98c193200c2b1c28c35bf382
This reduces the runtime of database-bound tests by about 40%
(on my system, from 4:55 to 2:47; results from Jenkins are
inconclusive).
The basic idea is to call addCoreDBData() only once, and have
a addDBDataOnce() that is called once per test class, not for
every test method lie addDBData() is. Most tests could be
trivially be changed to implement addDBDataOnce() instead of
addDBData(). The ones for which this did not work immediately
were left out for now. A closer look at the tests that still
implement addDBData() may reveal additional potential for
improvement.
TODO: Once this is merged, try to change addDBData() to
addDBDataOnce() where possible in extensions.
Change-Id: Iec4ed4c8419fb4ad87e6710de808863ede9998b7
Removed redundant set up in these classes (same as their paren
class MediaWikiLangTestCase does already).
* BlockTest
* ExportTest
* MWTimestampTest
* TitlePermissionTest
Change-Id: I28d18cb797bb249981727b02dffce4f0d8682b02
User::setId() has no effect on User::addToDatabase whatsoever,
and directly messing with the database is fragile due to
internal ID caching. Just use the insert ID instead.
Change-Id: Ib92f2b6d73deacaec90dc06634d8b3ad195d53e3
AuthManager is coming, which will make it easier to add alternative
methods of authentication. But in order to do that, we need to finally
get around to ripping the password-related bits out of the User class.
The password expiration handling isn't used anywhere in core or
extensions in Gerrit beyond testing for expired passwords on login and
resetting the expiry date on password change. Those bits have been
inlined and the functions removed; AuthManager will allow each
"authentication provider" to handle its own password expiration.
The methods for fetching passwords, including the fact that mPassword
and other fields are public, has also been removed. This is already
broken in combination with basically any extension that messes with
authentication, and the major use outside of that was in creating
system users like MassMessage's "MediaWiki message delivery" user.
Password setting methods are silently deprecated, since most of the
replacements won't be available until AuthManager. But uses in unit
testing can be replaced with TestUser::setPasswordForUser() immediately.
User::randomPassword() and User::getPasswordFactory() don't really
belong in User either. For the former a new PasswordFactory method has
been created, while the latter should just be replaced by the two lines
to create a PasswordFactory via its constructor.
Bug: T47716
Change-Id: I2c736ad72d946fa9b859e6cd335fa58aececc0d5
Block::__construct now accepts an array of options instead of a myriad
of optional parameters.
Also add a test for the old constructor.
Change-Id: I6ccd4df569ab49ad841a1ad591e23cafb1715841
This is an attempt to make BlockTest not to fail
with database referential constraints enabled
(from I326bb4a189bf881299b9fb678033a927b916efac)
Bug: 58191
Change-Id: I45c2d466f77d4d0aa25e880b5bb7d1120c39a561
One use found in core or Gerrit extensions which was replaced.
* Block::clear() (deprecated in 1.18)
* Block::decodeExpiry() (deprecated in 1.18)
* Block::encodeExpiry() (deprecated in 1.18)
* Block::forUpdate() (deprecated in 1.18)
* Block::infinity() (deprecated in 1.18)
* Block::load() (deprecated in 1.18)
* Block::newFromDB() (deprecated in 1.18)
* Block::normaliseRange() (deprecated in 1.18)
* Block::parseExpiryInput() (deprecated in 1.18)
Change-Id: Ia8ea6b5248111326f929062346f3868a0550421b
Move the block insertion to addDBData(), and use a provider to
itterate through the test strings.
This seems like the more correct way to run these tests, although it
still seems hacky, since the db isn't cleaned up after each test.
Change-Id: Ib22ce69797ec03a61b0cc330e8572865290ebd31
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3faa9c3e8107c6e46cdf21f8c18adda1f42890d7
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3e38b94d10600a60d2d4857de54307f34c4662c4
Fix almost all occurences of the following sniffs:
Generic.CodeAnalysis.UselessOverridingMethod.Found
Generic.Formatting.NoSpaceAfterCast.SpaceFound
Generic.Functions.FunctionCallArgumentSpacing.SpaceBeforeComma
Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLine
Generic.PHP.LowerCaseConstant.Found
PSR2.Classes.PropertyDeclaration.ScopeMissing
PSR2.Files.EndFileNewline.TooMany
PSR2.Methods.MethodDeclaration.StaticBeforeVisibility
Change-Id: I96aacef5bafe5a2bca659744fba1380999cfc37d
This caused about 200 exceptions "MWException: Error in MediaWikiLangTestCase::setUp(): $wgLanguageCode ('fr') is different from $wgContLang->getCode() (en)" on my installation.
Change-Id: I2987db68e22b27d8d36cdae118356fd7612e56a4
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
This patch adds BlockTest::testBlockedUserCanNotCreateAccount() which
test that a new user can createaccount and that blocking him will
prevents to the createaccount right.
Does not solve bug 38333 though!
Change-Id: Ia10e26825d50d47b4770900ee91dea666337f969
Change 1:
* Delete any pre-existing block for the tests
* Renamed test function and fixed comment typo
Change-Id: I4804ccae81dd0455e9d3ddf48960c4b5cd6e4f5f
difference.
Otherwise if the test happens to be run on a second barrier, it could
falsely fail (like it did just now when codur said some hurtful things
about my code failing unit-tests where it really didn't ;)
Some of the other block tests seem to itermitantly fail for no appearent
reason (null comes back instead of the block)... I don't know why.
It was accidentally passing a username where it should have passed a user ID, causing PostgreSQL's stricter comparisons to fail, while MySQL's allowed it to run without complaint but returned bad results.
Of course that bug got hidden by the test.... testing the wrong thing... :)
Now correctly loads using the user id instead of name, checks the proper return values, and actually compares the right object.
