Done:
* Replace LanguageConverter::newConverter by LanguageConverterFactory::getLanguageConverter
* Remove LanguageConverter::newConverter from all subclasses
* Add LanguageConverterFactory integration tests which covers all languages by their code.
* Caching of LanguageConverters in factory
* Make all tests running (hope that's would be enough)
* Uncomment the deprecated functions.
* Rename FakeConverter to TrivialLanguageConverter
* Create ILanguageConverter to have shared ancestor
* Make the LanguageConverter class abstract.
* Create table with mapping between lang code and converter instead of using name convention
* ILanguageConverter @internal
* Clean up code
Change-Id: I0e4d77de0f44e18c19956a1ffd69d30e63cf51bf
Bug: T226833, T243332
Released just now.
Many old suppressions can now be removed. Enabling the issue for
undeclared variables is left to do later, given that there are
roughly 200 warning.
Change-Id: I99462a1e9232d6e75022912e2df82bc2038476ef
Before this, authentication error messages are custom built and do not
contain as much information as block error messages for other actions.
They also assume the block target is either an IP or an IP range, and
have no customisation for different types of block.
Instead, this uses the BlockErrorFormatter to choose the most
appropriate and informative message for the block.
Bug: T227110
Change-Id: I942ac605075b6c2174682c7e75fe1213f82ebea2
This reverts commit 5f06efb318, which
reverted 9335363789, which makes
the deprecated property AbstractBlock::mReason private.
After 9335363789, AbstractBlock::mReason is obsolete, since the block
reason is now stored as a CommentStoreComment, AbstractBlock::reason.
Change-Id: Ica0a74be90383689ca8e4cfe6d0fb25c9a5942c5
This reverts commit 9335363789.
Reason for revert: It's full of code accessing AbstractBlock::mReason
out there, see [1]. Also, it was never hard deprecated. While that may
be acceptable under some circumstances, it's definitely not OK to remove
code when there are consumers around. I'd have fixed it right now without
reverting if it were a single repo, but there's just too many.
[1] - https://codesearch.wmflabs.org/search/?q=-%3EmReason&i=nope&files=&repos=
Change-Id: I8669f502b50cff89e28dada0f65fe2b130ae9b37
AbstractBlock::setReason now accepts a string, Message or
CommentStoreComment. The CommentStoreComment is accessed via
AbstractBlock::getReasonComment.
AbstractBlock::getReason returns the reason as a string, with
the language and format consistent with how block reasons were
built before this commit. This method is deprecated, since it
makes assumptions about the language and format needed. The
deprecated mReason property is no longer public.
Doing this (and T227005) will remove the implicit dependency of
BlockManager::getUserBlock on language, which causes a recursion
error if the block is checked before the user has loaded. It also
provides a mechanism for getting the block reason in a language
specified by the caller. (This does not apply to DatabaseBlock
reasons entered via the Special:Block form, which were not and
are still not translatable.)
This commit also updates authentication classes to return the
translated reason.
Bug: T227007
Change-Id: Iec36876e930dff96a256aebbdc39cbfb331c244e
Keep Block as a deprecated class alias for DatabaseBlock.
Update calls to the Block constructor and Block static
methods from external classes.
Also update documentation in several places that refer to
blocks as Blocks.
Bug: T222737
Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
This introduces a minimal BlockManager service, for getting blocks
that apply to a User.
Move the part of User::getBlockedStatus that checks for the blocks
into BlockManager::getUserBlock, and move the related helper
methods from User to BlockManager.
Hard deprecate or remove these helper methods, and move to private
methods in the BlockManager:
* User::getBlockFromCookieValue
* User::isLocallyBlockedProxy
* User::inDnsBlacklist
Soft deprecate these helper methods, and move to public methods in
the BlockManager:
* User::isDnsBlacklisted
Add tests to cover the methods moved to BlockManager.
Bug: T219441
Change-Id: I0af658d71288376735cebe541215383b56bb72e5
Its return value was already not used. By using runWithoutAbort()
it means that if a hook accidentally returns false, it will throw
an exception instead of silently skipping other hook handlers.
This type of mistake has repeatedly caused problems in WMF prod
over the years.
Change-Id: I6af2261957eb20f18fa5f0d50c4c4835d3850cfe
Use getters and setters for $mReason, $mTimestamp, $mExpiry and
$mHideName; use Block::getType to check if a block is an autoblock
instead of checking $mAuto; no change needed for $mParentBlockId,
which is not accessed externally.
Change-Id: I767ed44ce4c2e21f53962d75fb86891add2282f6
AuthManager::autoCreateUser() causes createAndPromote.php to give error
"Automatic account creation is not allowed." when
$wgGroupPermissions['*']['createaccount']=false is set. Anonymous user
checks should be skipped for maintenance scripts.
Change-Id: Ib61889a758e542abe991707d8b7853a25cfed8e9
Use AuthManager::autoCreateUser when creating a new user via
createAndPromote.php so that configured AuthManager providers have
a chance to perform validations and extra actions beyond local account
creation.
Bug: T212689
Change-Id: I4972507bbaf65bb542934c281c37bd8a5c7a26b7
Authentication audit logs should indicate whether a login is via the
normal password or a bot password (and which one). For failed logins
it could be included in the error message, and it usually is, but
for successful ones there is no message, so we'll send the app ID as
a new AuthManagerLoginAuthenticateAudit parameter.
Bug: T194338
Change-Id: I8aab48177b81a8e80dae118e6476a8f6a32089f1
Depends-On: Id482d2e2205960a0facd334e456d3a23bcad0ece
Updated unit tests as well for AuthManagerTest::testContinueAccountCreation()
and AuthManagerTest::testContinueAccountLink().
Change-Id: I96363e34688517796c2812cb3f483e1bfa26be6b
$user->getId() returns an int and it's strict on this,
so the check here should be an identical check as "=="
does unnecessary coercion. So "===" will be faster and
improves on speed/performance.
Change-Id: I28a4e86ab339f10251df8846b8d951b673fe4f9e
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.
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
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
Logstash merges the log context into the main metadata (where
'message' is the log message) and ends up overwriting the message.
Bug: T145133
Change-Id: I27f221b0f1f7203e93d1b92119dc584ba8526f5b
AuthManager tries to check whether the user already exists if
User::addToDatabase fails in autocreation, but since the same DB row
was already checked a few lines earlier and this method is typically
wrapped in an implicit transaction, it will just re-read the same
snapshot and not do anything useful. addToDatabase already has
a check for that so let's rely on that instead.
Bug: T145131
Change-Id: I94a5e8b851dcf994f5f9e773edf4e9153a4a3535
* 81be9512a022 should obviate the main desire for this.
The normal commit step is now relied upon again.
* 820f5d6ce5 and a26fbb6705 enforce DBO_TRX transactions.
* Committing the implicit transaction(s) prematurely is bad
for web request and cross-DB transactionality. Only code
that has clear outermost DB context (e.g. jobs/maintenance)
should be doing things like this as it becomes hard to reason
about (e.g. how much the request/caller needs atomicity
or whether there is an outer (start|end)Atomic section).
This reverts commit 83c66caa08.
Change-Id: I1a5533b239e53f2089f239651c6fdf97e51c9062
AuthManager::getAuthenticationRequests() changes
AuthenticationRequest::$required from REQUIRED to PRIMARY_REQUIRED
if the request is from a primary; it made an exception when
all primary providers returned a given request. That exception is
not particularly useful (AuthenticationRequest::mergeFieldInfo()
used to rely on it to determine which fields are required, but
since I9d33bd2 that's not really needed), and knowing which request
is from a primary is useful for other means.
This changes required field semantics in a corner case: when a
primary provider returns two required requests, the previous
behavior was to assume that they are both required; the new one
is to treat them as alternatives (as if they were returned by
two different providers). So when all primary providers return
request X, and one of them returns Y in addition, the fields of X
will not be marked required, while previously that would have been
the case.
Instead of overcomplicating the interface for something that is
unlikely to come up in any real use case, add a new requirement
to PrimaryAuthenticationProvider that it should not return
multiple required requests.
Bug: T141471
Change-Id: I1c1f44d4d6b66f77c876e3459fb97f03483db744
