The hooks that used to be called by this class will be removed in
I24d6fa963. The only reason to keep this class around is that
someone might have added it to $wgAuthManagerConfig so removing
it would trigger class lookup failures, so make sure any use
of the class triggers a deprecation warning.
Change-Id: I9755288eda7461ecf3dcd35de2081fbb3eb04ae3
Instead of having basically every caller do:
$pf = new PasswordFactory();
$pf->init( RequestContext::getMain()->getConfig() );
Just create a single PasswordFactory via MediaWikiServices and pass that
around. Things that want to use their own config can still pass settings
via the new constructor.
This will eventually let us remove the init() function, removing the
only hard dependency upon MediaWiki, to make it easier to librarize
(T89742).
Change-Id: I0fc7520dc023b11a7fa66083eff7b88ebfe49c7b
There's a difference between addition of credentials, which doesn't
need to invaliate BotPasswords, and changing or removal of credentials,
which does.
It seems most straightforward for the caller of
AuthManager::changeAuthenticationData() to know which is intended, so
let's add a flag there.
Bug: T199809
Change-Id: Ib8405734e605b94f3f0b66596ad95784cb365e4f
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
`$a <=> $b` returns `-1` if `$a` is lesser, `1` if `$b` is lesser,
and `0` if they are equal, which are exactly the values 'sort()'
callbacks are supposed to return.
It also enables the neat idiom `$a[x] <=> $b[x] ?: $a[y] <=> $b[y]`
to sort arrays of objects first by 'x', and by 'y' if they are equal.
* Replace a common pattern like `return $a < $b ? -1 : 1` with the
new operator (and similar patterns with the variables, the numbers
or the comparison inverted). Some of the uses were previously not
correctly handling the variables being equal; this is now
automatically fixed.
* Also replace `return $a - $b`, which is equivalent to `return
$a <=> $b` if both variables are integers but less intuitive.
* (Do not replace `return strcmp( $a, $b )`. It is also equivalent
when both variables are strings, but if any of the variables is not,
'strcmp()' converts it to a string before comparison, which could
give different results than '<=>', so changing this would require
careful review and isn't worth it.)
* Also replace `return $a > $b`, which presumably sort of works most
of the time (returns `1` if `$b` is lesser, and `0` if they are
equal or `$a` is lesser) but is erroneous.
Change-Id: I19a3d2fc8fcdb208c10330bd7a42c4e05d7f5cf3
Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
These comments do not add anything. I argue they are worse than having
no comments, because I have to read them first to understand they
actually don't explain anything. Removing them makes room for actual
improvements in the future (if needed).
Change-Id: Iee70aad681b3385e9af282d5581c10addbb91ac4
This is meant for private wikis where the list of users may
be secret. It is only meant to prevent trivial enumeration
of usernames. It is not designed to prevent enumeration
via timing attacks.
Bug: T134100
Change-Id: I7afaa955a4b393ef00b11e420709bd62b84fbc71
If a user being auto-created is blocked from account creation without a
reason given, CheckBlocksPrimaryAuthProvider is triggering a
"User::loadFromSession called before the end of Setup.php" log message
when trying to fill in a reason using 'blockednoreason'.
In this situation, use the content language instead.
Bug: T124367
Change-Id: Id94c919cdba5e4218b709ba8ac9d0fa17f0c3f8e
UserGroupsChanged is called in Special:UserRights with seven args
The caller in User.php only has five
Change-Id: I221da323c79bb8da0113533d01b429249d15e7de
Before this commit, the reason set in the global $wgReadOnly was differently handled
on different special pages. While on most of them, like Special:Upload, the reason
is allowed to have HTML, which can be used in Wikitext, too, Special:CreateAccount
always outputted an escaped version of this reason.
Most special pages uses the ReadOnlyError exception to print a read-only error,
however, AuthManager uses Status objects to communicate between the backend and the
frontend. Therefore the same message and parameters were wrapped in a Status object
and, in the frontend, directly passed to the constructor of ErrorPageError. Unfortunately,
Status::getMessage() escapes the parameters of a message, which is the reason, why the
wiki is read-only. To bypass this restriction, AuthManager now creates a Message object
directly, does not escape the reason, and uses the resulting object to create a Status
object from.
Now the reason is not escaped on Special:CreateAccount anymore, like on most other
special pages.
The read-only message on the protection form is, also before this commit, not escaped and
already displayed correctly, as the read-only is checked in the constructor of the
protection form already and, if the Wiki is read only, handled as a permission error and
already displayed correctly. This commit fixes the behavior of WikiPage in case of it's used
somewhere else, subclassed or if the check in the frontend will be removed and the Status of
WikiPage will be used.
Bug: T157036
Change-Id: Idbfe556fcb90f8bda8fae9d728ca9dee5ea02f67
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
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
The `type` log event attribute is used in Wikimedia production logging
to categorize log events by source (e.g. 'mediawiki', 'restbase', etc).
Adding a `type` key to the logging context overwrites the default value
of 'mediawiki'. Rename the key to `throttle` in the context and the
message template.
Change-Id: Ic274159774e43a8749f83c850fff7897956cf377
When the local password provider is in login-only mode, it should
disable itself as soon as some other primary provider is enabled.
It's impossible to tell whether that is the case though, so err in
the safer direction.
Change-Id: Ie77a9cc6d8f06aa52a893e753d9971e30b0f55e5
I found this confusing when reading the code. This should have
identical logic but slightly clearer.
Change-Id: I4918c29bd5dca3642de7bb60219fc246299d952d
