This introduces PageUpdater to replace WikiPage::doEditContent,
and DerivedPageDataUpdater, to replace WikiPage::doEditUpdates
and WikiPage::prepareContentForEdit.
See docs/pageupdater.txt for a description of their
functionality.
MCR migration notes:
* The interface of PageUpdater is expected to
remain mostly stable after this patch. Code that has been using
WikiPage::doEditContent can be confidently migrated to using the
new mechanism for revision creation.
* This patch keeps the code inside PageUpdater largely aligned
with the old code in WikiPage, to make review easier to to avoid
mistakes. It is intended to be refactored further, moving
application logic into stateless services.
* DerivedPageDataUpdate is intended as a stepping stone for further
refactoring. Its behavior is designed to be compatible with
callback code that currently relies on
WikiPage::prepareContentForEdit. Much of the code that currently
lives in DerivedPageDataUpdate should be factored out into
services, all behavior relevant to calling code should be exposed
via narrow interfaces.
Bug: T174038
Bug: T196653
Change-Id: If610c68f4912e89af616cdcac1d35a1be3946afa
A cookie will be set when ip users try to edit and their IP has been
blocked or if they try to create an account and the block prevents
account creation
This feature is disabled by default and can be enabled by
setting the new $wgCookieSetOnIpBlock config variable to true.
Note: this is meant to discourage vandals that try to avoid blocks by
switching their ip address while editing anonymously.
Bug: T152462
Change-Id: I0b78a5e174bcd882edea39e868a08f9a347f5aba
If a block is deleted and ->clearInstanceCache() is called to try to
make an existing User object reflect that fact, some methods are still
reflecting the old block.
To fix this, User::getBlockedStatus() needs to clear all the relevant
instance variables if the user is found not to be blocked.
Change-Id: I6ad8d5555a4c8519336aded3067e5034831dadf3
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
This makes things centralized to reduce maintenance cost and also
enables me to use this methods in Wikibase to handle RC injection
Bug: T185034
Change-Id: Ic8c602e316144ccb5b05c69a0cc607cd53e38912
These tests apply to things that are not relevant to PHP code coverage,
such as testing presence of messages, JSON files, or the PHPUnit tests
themselves.
Using @coversNothing indicates that there is no code here to be covered,
and prevents warnings when using --strict-coverage mode (T152923).
Change-Id: Id89ee2c15a3ce3f10e34b13fb677cd1af75af9e6
Also, un-register the PerofmrRetroactiveAutoblock hook from CheckUser
as it will assume an IP address for the user which is not specified in
UserTest. This will keep the unit tests focused on unit testing, as
opposed to integration.
Bug:T176103
Change-Id: I3a090f7bae5ba266c3cd4500ecf83338fb8503bb
testExecute_email() should unregister the hooks
mailPasswordInternal and SpecialPasswordResetOnSubmit
for proper unit testing.
Bug: T176102
Change-Id: Id7403f57cc9d751ada85b611193c1d8f3503e713
This works by using the new table introduced with T156318.
The only thing that differs from normal Special:Contribs is we are
showing the IP address next to each entry. This is it how it is
displayed if you request to see newbie contributions:
https://en.wikipedia.org/wiki/Special:Contributions?contribs=newbie
For the time being, Special:DeletedContributions does not support
IP ranges. Various other irrelevant links such as Uploads and Logs
are also hidden.
Refer to P4725 for a way to automate creation of edits by random
IPs in your dev environment.
IP::isValidBlock() has been deprecated with this dependent change:
https://gerrit.wikimedia.org/r/#/c/373165/
Bug: T163562
Change-Id: Ice1bdae3d16cf365da14c6df0e8d91d2b914e064
This avoids postgres failures when trying to insert users with name
"false" (cast to 0, which fails since integer != text type).
Bug: T75174
Change-Id: I809edd94117811d22492eaba440fad6aaea1195b
Instead of using array_* functions, use the IPSet for checking, if a
specific IP address matches a set of addresses.
This also deprecates a backward-compatibility functionality, that
the wgProxyList array could also be an associative array, where the blocked
IP address is set as a key of the array insted of a value. All IP address
keys will be mved to values on-the-fly, however a deprecation warning will
be emitted. A notice in the Release notes was added, too.
Bug: T161580
Change-Id: I69d9534942c415ab044177969ecd54160079b593
Replaces \TestingAccessWrapper (defined in core) with
\Wikimedia\TestingAccessWrapper (defined in the composer package
wikimedia/testing-access-wrapper).
See https://gerrit.wikimedia.org/r/#/q/topic:librarize-testing-access-wrapper
for downstream patches.
The core version of the class is kept around for a while to avoid
circular dependency problems.
Bug: T163434
Change-Id: I52cc257e593da3d6c3b01a909e554a950225aec8
The default will remain PHPUnit 4.x due to PHP 5.5 support.
But, we should allow developers to run tests with newer PHPUnit
versions which are noticably faster (especially for code coverage
reports).
* <https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-5.4.0>
PHPUnit 5 deprecates the getMock() shortcut for getMockBuilder()->getMock().
It instead introduces the shortcut createMock() which has better defaults
than getMockBuilder(). For example, it sets 'disableArgumentCloning' and
other things by default.
Going forward, code should either use getMockBuilder directly and configure
it using the setter methods (instead of the confusing variadic arguments
of getMock) or simply use the new minimalistic createMock method. This patch
backports the createMock method to MediaWikiTestCase so that we can start
using it.
Change-Id: I091c0289b21d2b1c876adba89529dc3e72b99af2
Let there be highlight! and there were highlights
And RCFilters separated the highlight from the darkness
And it defined highlights as five colors
The lights are called yellow and green, and the darks red and blue
And there were colors and there were circles; one highlight.
This is the commit that adds highlight support for filters both in the backend
and the UI. The backend tags results based on which filter they fit and the
front end paints those results according to the color chosen by the user.
Highlights can be toggled off and on.
Also added circle indicators to the capsule items and each line of results
to indicate whether the line has more than one color affecting it.
Bug: T149467
Bug: T156164
Change-Id: I341c3f7c224271a18d455b9e5f5457ec43de802d
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
This change adds a HMAC to the block-cookie to prevent someone
spoofing a cookie and so discovering revdeleted users' names.
The HMAC is only added if $wgSecretKey is set; if it isn't, the
existing plain-ID format is used. A note about this has been
added to DefaultSettings.php.
Tests are updated and new tests added to demonstrate an
inauthentic HMAC, and for when $wgSecretKey is not definied.
Bug: T152951
Change-Id: I6a3ef9e91091408c25eaa2d36d58b365d681e8c6
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
In https://gerrit.wikimedia.org/r/80061/, Chad was convinced this
preference is barely used and mostly set to weird values by people
who don't understand what they're doing.
He made some quick stats: http://p.defau.lt/?fgGU0StB4J9l0LC5GZq8AA
Used defaults of 80 columns and 25 rows in places that still
were asking for it. The old default values are left in
$wgDefaultUserOptions for now, since various extensions are
using them.
The 'rows' and 'columns' messages don't appear to be in use in
any extensions in Git, so I killed those as well.
(This is the same as I642188c74d929a586b1882a1cf8656056c4fcf5a.)
Bug: T26430
Change-Id: I6c9802bc4f9cf32fb75c3dd7b9e2dc18f271eedf
This variable allows for blocking anonymous contributions from certain
IP addresses. Account creation from these addresses will be allowed.
The idea here is that, for example, Wikimedia could add 10.0.0.0/8 to
prevent logged-out bots on labs from making confusing edits. See
I74f5f4a3.
The default for the new variable is empty to avoid causing issues on
upgrade for wikis on private networks.
Change-Id: I6c11a6b9e1a740de074e7ccd753418f94c4b6288
Rather than use wgCookieExpiration as the basis for the maximum
life of a block cookie, just use 1 day.
Tests have been updated also.
Bug: T153347
Change-Id: I3447d97af3170308834f365c5c600430f47c66a7
This changes a test of expiry dates to be a 10-second range,
to account for slow testing. For example, a test may start and
set the block's expiry in one second, but by the time it is
reading the value from that block's cookie it can sometimes be
the next second. Making it 10 seconds just gives it more room
for being slow.
Bug: T153527
Change-Id: I5efde7785134a75487d31ef3d8b7b14f53b7f5d0
If anyone wants such a thing, they can make their own extension.
I asked stewards, and they said they don't use this.
See also T32636 / 9de2bfd1fe
Bug: T150930
Change-Id: I3ab5962dba668e5d628e55ad0c0feae471d82b5e
Send a cookie with blocks that have autoblock turned on so that
the user will be identified to MediaWiki and any IP they try
to edit anonymously from will be blocked, even without logging
in to the originally blocked account. Additionally, the block
info is stored in local storage as well as an even stronger
deterrence.
Note: this is meant to deter normal vandals, i.e., not attackers
who know what cookies and local storage are and will be actively
removing the cookie.
This feature is disabled by default, and can be enabled with the
new $wgCookieSetOnAutoblock configuration variable (by setting
it to true);
The cookie will expire at the same time as the block or after
$wgCookieExpiration (whichever is sooner).
Bug: T5233
Bug: T147610
Change-Id: Ic3383af56c555c1592d272490ff4da683b9d7b1b
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
An @ in the username caused the password to be treated as a bot password,
but apparently some real usernames still contain it. Try both logins
instead. Security considerations are the same as for the other bot
password syntax: the length check makes sure we do not provide any
information on a timing side channel about the password unless it is
extremely long.
Change-Id: I58f42544a08c3208c41f54cfae932632d9c5affa
Bot passwords allow backwards-compatible login (with grants, for API
usage only) with "<real username>@<botname>" for username plus a
random-generated password.
This doesn't work well with some bot frameworks (including Pywikibot,
the most popular one) which assume that the text that goes into the
username field of the login API is the username that they will be
logged in with afterwards (and so the @-postfix causes all kinds of
errors).
Since the goal of bot passwords is compatibility with old unmaintained
API clients, this patch adds an alternative format which does not
cause problems with old bots: use the username normally, and use
"<botname>@<random-generated password>" as password. Since this is
technically a valid normal password, there is some ambiguity, but
bot passwords have a distintive format so it's easy to check and it is
extremely unlikely that someone would use the exact same format for
their normal password; and if the bot password login fails we can
simply retry it as a normal password, just in case.
Bug: T142304
Change-Id: Ib59a6fbe0e65d80d5e7d19ff37cec5e011c00539
This prevents hook functions from accidentally adding rights that should
be denied based on the session grants.
If some extension really needs to be able to override session grants,
add a new hook where the old call was, with documentation explicitly
warning about the security implications.
Bug: T139670
Change-Id: I6392cf4d7cc9d3ea96554b25bb5f8abb66e9031b
Whenever User::incEditCount() is called,
this tries to keep the user object up
to date so hooks can read the edit count
without reloading the user from the db.
Another option would be invalidate the
instance cache and let the read
repopulate it. It would add a db access
on each edit.
Bug: T128249
Change-Id: I79194c41d6b2fd84ad658909a2941d9d3d28d94e
The unit tests spend nearly half of their run time resetting the user table for
each test. But the majority of tests do not depend on the user table having the
exact value that the setup code resets it to, and do not need to modify the
user objects they require to run.
Fix that by providing an API for tests to get User objects, and to indicate
whether the User object will be subject to destructive modification or not.
This allows User objects to be reused across multiple unit tests.
Change-Id: I17ef1f519759c5e7796c259282afe730ef722e96
