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
I13d0e402f fixed a MySQL strict-mode bug by having boolean false be
sent to the database as 0 rather than "", since so many of our
logically-boolean fields are typed as tinyints. That happened to also
cause logically-false user preferences to be stored in the
user_properties table as "0" rather than "", which works fine in PHP but
confuses JavaScript since it considers string-0 as truthy rather than
falsey.
To avoid this situation, convert "0" to 0 when loading the user
options. Completely solving T54542 is left for another time, since
identifying which type to normalize each option to seems nontrivial.
Change-Id: Ia3280b7ce923641eac077141b47cba10d3fb88db
The block cookie was being replicated to localStorage in an attempt
to make it harder for users to get around the block by deleting the
cookie (and changing IP addresses).
This whole setup was hard to test, had a few bugs (e.g. the localStorage
value would never expire), and given that it is a minor improvement
over just a plain cookie, it is now being removed. The cookie is only
intended to stop casual block-evaders (other users will get around it
by deleting the cookie or using incognito mode) and so it is not felt
worth having the extra complexity that will only guard against people
who know to remove cookies, not use incognito mode, and yet don't know
to remove localStorage.
Bug: T152952
Change-Id: Ifb06dc2390f4d648d7fcb39e30267de5eddc6941
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
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: I6f59febaf8fc96e80f8cfc11f4356283f461142a
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
These have both been deprecated since 1.24
Hard deprecation happened back in 2014
Both methods are still used by the SecurePasswords
extension, but this extension is documented on mw.org
as not working with MW1.24+.
I can find no other uses.
Lets finally get rid of these!
Change-Id: I94a7b65d2216bbc505e190af3182de2317976ed1
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
* This fixes keys based on some sort of change log.
Updates are wrapped in a mutex and keep track of the
last known good position.
* Make WANObjectReapUpdate class that cleans up title
related keys using the recentchanges table. This triggers
as a deferred updates on RC view.
Change-Id: I7f14b9ca2533032147e62b1a3cc004a23da86579
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
Deprecated and stubbed in 1.27, only throws exceptions these days.
The only user in core or extensions is AjaxLogin which is completely
broken anyway (T153385).
Change-Id: I298fbc3e65d98b3af2f3cfef3d9884e277e6717c
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 is a pure documentation change. It mostly removes empty lines from
comments (and entirely empty comments), as well as adds a few missing
documentation blocks and fixes a minor mistake. I hope it's ok to have
this in one patch. I can split it, please tell me.
Change-Id: I9668338602ac77b903ab6b02ff56bd52743c37c4
Otherwise callers that don't use 'steal' is going to break because it'll
think it needs to steal the user.
If such a user exists on a wiki, it can be fixed by setting the token to
the invalid token. The easiest way is probably to just call
User::newSystemUser( $name, [ 'steal' => true ] ) with eval.php.
Note there's no way for anyone to use these users unless they steal the
token from the DB, since they still don't have a password, email, or any
other method of authentication or account recovery set up.
Change-Id: I9efd2d2f5fffb4e4411a894f9514cdf2c66663a9
This was added in I56b6600 in an attempt to work around a bug in
CentralAuth, but the bug has since been fixed in a better way. No hook
functions in Gerrit use the parameter (or ever have, as far as I can
tell), and anything that was passing a value other than the default
'login' has since been removed. So let's just get rid of it instead of
keeping it around doing nothing.
Change-Id: Ie604e03d268706221161ac93eb866f477e466fb4
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
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
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
