$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
As things stand now, DBO_TRX or DBO_DEFAULT will cause a transaction to
be started, and then anything in the entire request failing will
probably cause the newly-added user row to be lost. But updates to
external databases (e.g. CentralAuth) likely won't be since those DB
connections were probably shut down after the update was completed.
So let's explicitly commit changes af the end of auto-creation so that
problems with the request itself don't undo it.
Bug: T119736
Change-Id: I6c13c8feb86d8b9a01df894733c38445d048fea0
This will allow providers to know whether the call is just for testing
(from ApiQueryUsers) or for actual creation, and skip duplicate work
when testForAccountCreation() is going to be called.
Change-Id: Id3ef713fd377135d78f66e5100dedd4689293b59
Depends-On: I4af8b3b692f60c42f8685b90be5936da7ba4e2e2
Depends-On: Ie9639a15d04b387be0e72754301eb6d91cd8adc2
Depends-On: I063cbdfbd9a223bf2391fce2b714ab82ddd3272f
Depends-On: I7c67512634f6e72251911238f083857da9fd3f84
Most of the time the context language won't be ready yet, because it
needs the user we're auto-creating.
Bug: T124367
Change-Id: I0376647be33e81593101378217b37363125cfddf
In Ic8caf57eb, we changed things so the requests returned in a UI or
REDIRECT response would have the action forced to that appropriate for
the action being peformed. But ResetPasswordSecondaryAuthenticationProvider
has a use case where a mismatch is necessary: it's run during the login
action, but it needs a PasswordAuthenticationResponse for a change
action.
Bug: T136894
Change-Id: I9d109a22c5b2d2064f664f584100ecaab43199c5
We only want to set the local user_token when we create the local
account. We don't want to invalidate all existing CentralAuth sessions
for the user just because they happened to visit a new wiki and get
an account auto-created.
This might also fix T136853. It looks like what's going on there is that
two jobs are both in this code path calling CentralAuth::resetAuthToken()
at the same time, leading to a race and one fails the CAS check.
Bug: T136834
Change-Id: I61b8253584a11a5b02f7ccb9efa0679cd2a822c6
I found a need in CentralAuth to check that
CentralAuthPrimaryAuthenticationProvider is actually in use, so I'm
exposing this.
Change-Id: I40bd3dc4d05db0c3a34b01f550a9a9a1ded8fc61
They were coming out as null instead, which screws up when requests are
changing their fields based on the action.
Change-Id: Ic8caf57ebad35c3eb17d45f9d96c6de5b559a83a
* ApiQueryAuthManagerInfo will differentiate between preserved linking
data and a preserved createRequest.
* ApiQueryAuthManagerInfo will indicate the preserved username, if any,
because the client will have to pass that back to action=createaccount.
* ApiClientLogin won't tell about the confusing
CreateFromLoginAuthenticationRequest returned on RESTART responses.
* Explain how 'preservestate' works in ApiAMCreateAccount's auto-doc.
* ConfirmLinkSecondaryAuthenticationProvider will filter out requests
that can no longer be used (i.e. if it was for linking the account
that got used for creation).
* All the complicated code in AuthManager::beginAccountCreation() was
trying to deal with allowing the client to pass only the
CreateFromLoginAuthenticationRequest. That was dumb, removed it.
* Added methods to CreateFromLoginAuthenticationRequest to indicate its
status with respect to different kinds of preserved state.
* Increase accuracy of the AuthenticationResponse::$createRequest doc.
Change-Id: I726d79de18e739d6e60c1eea51453433c21ba207
This implements the AuthManager class and its needed interfaces and
subclasses, and integrates them into the backend portion of MediaWiki.
Integration with frontend portions of MediaWiki (e.g. ApiLogin,
Special:Login) is left for a followup.
Bug: T91699
Bug: T71589
Bug: T111299
Co-Authored-By: Gergő Tisza <gtisza@wikimedia.org>
Change-Id: If89d24838e326fe25fe867d02181eebcfbb0e196
