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
It may be reasonable to ignore the 'noratelimit' right granted to a user
when perfuming some rate limit checks. As an example, a rate limit check
on failed authentication attempts should not be bypassed.
Add an optional '&can-bypass' configuration option for each
$wgRateLimits action that can be set to false to disable checking
User::isPingLimitable(). This bypasses both 'noratelimit' and
$wgRateLimitsExcludedIPs exclusions.
Depends-On: Iacdd1719d5f08eca91de0a35c0042ffee2136f34
Change-Id: Ia3add8bbbab0307f036e9b77e752c382da3a0d04
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
* This better handles delayed/lost cache purges by
having lower TTLs for entries that often changes.
* Use this for foreign upload description page caches,
we purges are never received from the source wiki.
* Also use this for User and LocalFile cache TTLs.
* Also move the Database::getCacheSetOptions() call in
User *before* doing the queries, which is preferred.
* Fixed some IDEA errors too, like the undeclared
mApiBase field.
Change-Id: I70f8ebb29ac853c2a530d9eedb9e7facc1b7b710
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
Does both Title and user related methods, so it catches things that only
call $wgUser->isAllowed( 'read' ), as well as giving a nicer error message
for things that use $title->userCan().
Otherwise, the user can still do stuff and read pages if they have an
ongoing session.
Issue reported by Multichill
Bug: T129738
Change-Id: Ic929a385fa81c27cbc6ac3a0862f51190d3ae993
This is likely not needed anymore to avoid deadlocks anymore
as AuthManagar uses a lock in autoCreateUser() before hand.
Change-Id: I19ae6562011854495efcb0dd832b7ae99ebbb224
When copying state from one User object to another, don't force
the source object to be initialized. The target object can initialize
groups and options on demand as usual.
Among other things, this helps to avoid some cases of recursive calls
to User::load(), see I6d1b9fe0789b4.
Bug: T142295
Bug: T137051
Change-Id: Ib369cf5b00628550591c2ee5dcb195db7c59a59c
Default options should be the same for all users. SearchEngineConfig::searchableNamespaces
however calls a hok that allows the set of searchable namespaces to be adjusted per user,
e.g. based on the user groups or permissions, like Extension:Lockdown does.
Since SearchableNamespace hook handlers may access the global user objects, problems arise
when it is that global user object trying to initialize itself that triggers the call to
User::getDefaultOptions. This can cause recursive calls to User::load(), see I6d1b9fe07.
Furthermore, these seems to be no need to actively record the searchable namespaces beyond
the contents of $wgNamespacesToBeSearchedDefault. If a 'searchNs' option is absent, it is
treated as disabled.
Bug: T142295
Bug: T137051
Change-Id: I5f6bcdfc588acef0873136bf338d79890863e009
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
MediaWiki uses an in-process cache to speed up repeat calls to
User::getDefaultOptions() -- except when the unit tests are running, in which
case the process cache is disabled, because otherwise it would be at risk of
becoming stale due to unit tests manipulating $wgContLang. Well, there's a less
aggressive option, which is to keep the cache enabled but use it only if
$wgContLang hasn't changed. Since MediaWiki's test setup code creates default
users for the unit tests, User::getDefaultOptions() ends up getting called
quite a lot, so enabling the process cache is worth the trouble.
Change-Id: I81f3ae42d356939c81e59ab12d7a9e7d1206cb40
This fixes a regression from 3bbccc8da6. A large uptick in
master queries showed in DBPerformance logs.
Change-Id: I5cf07aba2c3f928005d3aba55554c406e87026e2
Also update createAndPromote.php to use it so it can display errors.
Note that there are two possible approaches. The other is to
do the update for all requests for which the test passed,
even if some tests fail. The approach of the patch seems
more manageable from the caller's point of view
(either the operation was a success, or it failed and
nothing happened).
Change-Id: I86abed4b80472cd888337444fac0cbcb870b1246
AuthManager uses a status which is OK but not good for authentication
data which is discouraged but still accepted for authentication.
Users should not be allowed to change credentials into such invalid state.
This change brings the web logic and the AuthPlugin fallback in sync with
the API which already used the stricter check.
Change-Id: I4ff54fcc901f6fe11f15ed60fc1a3d8753de9f6c
