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
Rewrite authentication-related special pages to use AuthManager.
All the changes mentioned below only take effect when
$wgDisableAuthManager is false.
LoginForm is rewritten to use HTMLForm and split into UserLogin
and CreateAccount; ChangePassword and PasswordReset are rewritten;
ChangeEmail and Preferences are updated. Four new special pages
are added to handle the new capabilities of AuthManager (linked
accounts, secondary authentication providers): LinkAccounts,
UnlinkAccounts, ChangeCredentials, RemoveCredentials.
The old form-based hooks (ChangePasswordForm, UserCreateForm,
UserLoginForm) are deprecated. A new, more generic hook is
available to alter the forms (AuthChangeFormFields);
form changes that involve new fields should be done via
$wgAuthManagerConfig.
UserLoginComplete is limited to web-based login; for more
generic functionality UserLoggedIn can be used instead.
Hooks that assume password-based login (PrefsPasswordAudit,
AbortChangePassword) are removed; the first functionality
is replaced by ChangeAuthenticationDataAudit, the second is
handled by AuthManager. LoginPasswordResetMessage is removed,
the functionality can be recreated via authentication providers.
There are several smaller backwards incompatible changes:
* Adding fields to the login/signup forms by manipulating the
template via the extraInput/extrafields parameters is not
supported anymore. Depending on the authn configuration the
login/signup process might be multistep and it would be
complicated to ensure that extensions can access the data
at the right moment. Instead, you can create an
AuthenticationProvider which can define its own fields and
process them when the authentication is over.
(There is B/C support for a transitional period that works with
the default login form, but might break with configurations that
require multiple steps or redirects.)
* Removed cookie redirect check. This was added in 2003 in 9ead07fe9
for the benefit of bots, but with MediaWiki having an API these days
there is little reason to keep it. Same for the wpSkipCookieCheck
flag (added in 2008 in 29c73e8265).
* Instead of embedding a password field on sensitive special pages
such as ChangeEmail, such pages rely on AuthManager for elevated
security (which typically involves requiring the user to log in again
unless their last login was more than a few minutes ago).
Accordingly, wgRequirePasswordforEmailChange is removed.
* Special:ChangePassword requires login now.
* Special:ResetPassword now sends a separate email to each user when called
with a shared email address.
* the Reason field had a message with 'prefsectiontip' class
which was sorta broken but used in extensions for formatting.
HTMLForm does not support that, so this commit turns it into a help message
which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884
Bug: T110277
Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c
Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
* Speed up password generation and verification by setting MWOldPassword as the
default password type. Do this once, in MediaWikiTestCase::makeTestConfig(),
rather than in five different places.
* Rename '$pwhash' to '$passwordHash', for consistency. It's ugly to have both
'$passwordFactory' and '$pwhash' in the same scope.
* Make TestUser::setPasswordForUser() check first whether the desired password
is already set. This is actually the common case, since the password is reset
in the setup code for every test, but only a few tests actually change the
password.
Change-Id: I423f09ff7472b6cbde21cb709ea7c7ef9e298f18
User::getCanonicalName silently stripped namepace/iw prefixes,
resulting in weird behavior (e.g. entering 'Template:Foo' in the
registration form username field was accepted, but user 'Foo' was
created). Explicitly reject such names instead.
Also remove leading whitespace from test cases testing for something
else.
Bug: T94656
Change-Id: Idfb22f998cb069fca24abcf5809afd6e0324b0ae
