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
