CVE-2025-6926
This is a workaround for extensions with some sort of "autologin"
implemented via the login page to indicate that the login flow
didn't involve the user actually logging in, it merely copied
some central login state, and so isn't appropriate for the
reauthentication flag.
This isn't the best way to provide an interface to extensions
(if we keep it, a more explicit interface, such as a
SessionPropertiesAuthenticationRequest object that's part of
the initial request set and can be modified by providers,
and can also be used for the "remember me" flag, would be
nicer), and maybe the whole approach of letting extensions
suppress the reauthentication flag is not the best way of
handling the problem in the first place, but it's simple
which is important for a security patch.
Bug: T389010
Change-Id: Ifce73837b25b0caad2d3d3cba000cceb0184c29d
CVE-2025-6597
Auotcreation doesn't necessarily involve real-time user
identification, it can be based on some provider identifying the
user based on a session cookie or similar low-fidelity information.
Do not restart the reauthentication timer.
Bug: T389009
Change-Id: Icfb4d0ffe71a92421e8630a92ae302cc459aa9d6
Why:
- Using an anonymous user object at the start of account creation helps
ensure that downstream code paths do not record the association
between a temporary account and a named account
What:
- Use an anonymous user object during account creation initiated by
temp account users
- Update the session to use the anonymous user and set the request
context user based on the session user
- Ensure the temp account username is removed from the session, to avoid
issues where account creation fails and code thinks that a temporary
account username is already defined for the session
- Add a test to exercise this code path
Bug: T393628
Change-Id: I6d2df8c1d842c4fefa916ed395479f479a0051eb
(cherry picked from commit 3d80e63f109834b90a83597d6d924895b2c6ae71)
Why:
- Calls to callMethodOnProviders() specify bitmasks as decimal literals,
so it is not clear which authentication providers are being called
without referring to the doc comment and converting to binary.
What:
- Add four new private constants: three that match the values specified
in the doc comment, and one that is the bitwise OR of all the others.
- Use them throughout the class.
Change-Id: Ib67e5174f00a080e79f0b6f35c0eeec4b95b8d8e
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
Why:
- When signing up for an account, temporary users are currently forced
to provide a reason for creating an account, and also have the option
to send a temporary password to an email address.
- Neither of these options are useful for temporary users wanting to
create a full user account.
What:
- Don't show these two form fields on Special:CreateAccount for temporary users.
- Add a functional test for the temporary user account creation flow.
Bug: T328718
Change-Id: Ie545857f7647be89d9462ec2b0def48690f0a2bf
This allows a primary auth providers to update the "remember me" status
of another primary provider in the same login request flow. If authentication
that happened elsewhere and a "remember me" / "keep me logged in" (extended
login period is selected), the value of this action applied by the remote
primary provider should be applied to the local wiki when the user is
redirected back to continue authentication there.
This is useful because:
In the case of Wikimedia's central domain wiki in SUL3 mode, we want to
apply the remember me (keep me logged in) flag value from the central domain
to the local domain.
Bug: T369668
Change-Id: I6e2e2d892d2b777cb4757c7c0d222afad9da506c
Session providers can provide a `canAlwaysAutocreate` flag which
indicates account creation is exempt from autocreate permission
checks. This is used, for example, for providers that provide
users for supporting applications in a wiki farm.
Pass that information along to pre-authentication providers so
they can respect the intent of the flag. We cannot simply skip
pre-authentication, it's used for non-permission-related things
like preventing CentralAuth username conflicts.
Bug: T373778
Change-Id: Ie3aeaf48e615e2fb85b2069203ab91ca0127ae05
Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: Ib6081f5519d2294bb14f81bf399f9c45315f2b69
Update a few tests that relied on the feature flag to ignore
the 'requireemail' preference on "User1" to instead use "User2",
who doesn't have the preference set.
Bug: T242406
Change-Id: I996d3996272d704a071d1d2094c3568247b80f98
Add a new hook that can be used to prevent authentication just
before AuthManager takes the main action (writing the session
for login, creating the local user account for account creation).
The driving use case is a wiki which supports both a local and
a central (wiki-farm-level) login or signup flow - various
security options (such as 2FA) are needed during local login
but unnecessary during central login (which will have those
security features centrally), so we need to skip much of the
security when the user is taking the central route, and a bug
in how that's done could result in circumvention of security
features during local login. The hook makes it easy to inspect
and potentially interrupt login near the end, when we know for
sure what route it took. (Specifically, we know which primary
provider was used. The hook doesn't expose other details,
such as the list of preauth or secondary provders that were
invoked, because they were not needed for the immediate use
case, but they are easy to add in the future.)
The hook is called after the secondary providers for login
and before them for account creation, since secondaries can
interrupt login but cannot interrupt account creation.
A shortcoming is that since the hook is called after a primary
provider succeeded, it cannot prevent the primary provider from
doing work, ie. it cannot prevent creation of the remote account
during account creation (although it will prevent the creation
of the local account). This is not great but acceptable, since
creating a new account isn't very security-sensitive.
This also means the hook would not be useful during account
linking, as AuthManager does not do anything there, all the work
happens in the primary provider. This is even less great but
few authentication extensions implement account linking.
The hook is not called for authentication happening via
CreatedAccountAuthenticationRequest, which is a weird internal
hack hook handlers should not have to know about.
Also rename a confusingly named variable.
Change-Id: I835b2fe2f43e6e81f23348165cbb9c93832e6583
Allow disabling authentication providers. This allows for
extensions to replace core providers with their own.
This is using the $wgAuthManagerAutoConfig keys instead of
AuthenticationProvider::getUniqueId() as the keys to filter.
This makes it more useful for site administrators, and also
it's probably the better known of the two identifiers so
more intuitive.
No effort is made to prevent the hook from filtering
differently in different steps of the same authentication
process.
Bug: T369180
Change-Id: If5435b54a4fc08f685c04fc10eb44c6d72cd78fa
This is more convenient for callers since they can avoid the pattern
of setting $fname to __METHOD__ and needing $fname in the "use" clause.
This is also more consistent with AutoCommitUpdate/AtomicSectionUpdate.
Remove @since tags from @internal MWCallableUpdate class.
Change-Id: I67c58897dc366a55f43e0a61d56064b26d520c17
And deprecated aliases for the the no namespaced classes.
ReplicatedBagOStuff that already is deprecated isn't moved.
Bug: T353458
Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
Why:
- User::loadFromId must avoid doing a replica read when the newly
autocreated user record isn't replicated yet; that would turn $user
into an anonymous user object, and eventually log the user out.
The old code tried to avoid this by using the same recency flag
for which UserIdentityLookup::getUserIdentityByName() returned a
non-anonymous user identity, but that's not actually a guarantee
that the user is in the database, because getUserIdentityByName()
has an internal in-process cache.
- For a specific example of this, Icf6be65a91437aa32684769c2858 broke
temp account autocreation because inserting the log entry triggered
ActorNormalization::acquireActorId() which set the in-process cache.
With this patch applied, temp account autocreation will work again
on wikis with database replication setup.
What:
- Use READ_LATEST flag when loading a user in an account
autocreation context
- See also I5456f88ebb78d2fcac685efd4a1f7a9f60d2bc0e for a proposed
follow-up to this patch
Bug: T369372
Change-Id: I04932d84aa0b0b5939706f3905f0fe7700d81327
This hook enables extensions such as CentralAuth to preserve and
use query parameters needed for an authentication flow. Since there
is a provider that handles logins in a different wiki (central login
wiki), and movement to a different URL, this hook preserves query
parameters that can be used between these requests.
Bug: T363483
Bug: T362713
Change-Id: I86e629b07e6e4a0f1d1a4c78a6c77d41b4d68e18
Why:
* When a temporary account creates a named account, the 'newusers'
log currently links the temporary account username and the new
named account.
* This is an issue because temporary accounts are intended to be
anonymous and there is no path for a temporary account to
link their contributions to their new account. As such, there
should be no link between them.
What:
* Update AuthManager::continueAccountCreation to only mark the
performer of the 'newusers' log entry as the creator account
if the creator is named.
Bug: T364716
Change-Id: Ib95374949c5c72c9f7ee665943c16d177f2e31c0
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Id9f3e775e143d1a17b6b96812a8230cfba14d9d3
It was asked in a patch review to apply fully import
InvalidArgumentException where possible. I was guessing some
of my other already merged patches have but turned out such
thing exists other places style so for the sake of consistency
I've turned rest of inline import of the specific exception at
top of the file.
There are instances of source files that aren't in any namespace but
have fully qualified import which this patch doesn't touch.
Change-Id: I4071fc698b65746d9594cf4d5f45bae82843d436
Some of these have been marked in-code as deprecated for a long while,
but haven't ever been announced in the RELEASE-NOTES (and later,
HISTORY) file, so let's mark them up now so we can get the ball rolling
at least.
Per Gergo, the AuthManager one was 'born deprecated' and should only
have been used by humans also reading the deprecation notice given in
the code, and indeed no uses are known to code search, so also emit
deprecation warnings there immediately; others will have to wait until
uses have been migrated.
Change-Id: I0c1c71d8f4293623039302da35d58d2a24367e97
Why:
- We want to be able to reuse this method in other places, e.g. in
temporary user account autocreation
What:
- Move LoginSignupSpecialPage's setSessionUserForCurrentRequest method
into AuthManager, while splitting out the logic that is specific to
LoginSignupSpecialPage
Bug: T364121
Change-Id: I9c96420eca4a756cc846e4ff16e7698365b044d8
By doing this, auto-creation get available for users who use blocked IP and hold ipblock-exempt or globalblock-exempt, as autocreateaccount permission is checked on the user theirself rather than on anonymous IP user.
Bug: T316303
Change-Id: I2ad825317e900e865fffa39d4ea644f07beb4cf8
Signed-off-by: Bingwu Zhang <xtexchooser@duck.com>
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I24ca752d5dac7c948fdbcabf721f6f0aef8a466f
Fixed SkinModuleTest::provideGetFeatureFilePathsOrder as nesting of
arrays for parameters is wrong
Change-Id: I9875008adf62d284c48662ebfbd245d72e5be064
Why: the authentication mechanism replaces the user in session
(eg: anon, temporary user) for the logged in user in login
authentication requests. As a result neither postAuthentication
interface in AbstractPreAuthenticationProvider or the
AuthManagerLoginAuthenticateAudit hook provide information about
the user that performed the request, the "creator"
What: add the performer user of login requests to the $extraData
array when calling AuthManagerLoginAuthenticateAudit
Bug: T356249
Change-Id: I487c0da87a7215d3a49a8c432109205f8789247b
With Id3a316e relying on calling autoCreateAccount() multiple times, make sure the various login paths behave the same.
Change-Id: I3d3a1c9d4d8146f24451a7e9e5f407a6b24a3156
Soft-deprecated since 1.26 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I55e4569c5a40f77a719bc7ab1924eaa706e0da53
Adds a new method to the SessionProviderInterface that declares if the
session provide is exempt from user creation authorization. This is
intended to support use cases where the SessionProvider is providing
access to maintenance related users external to MediaWiki itself. For
example in a supporting application to a wiki farm. This lets the
SessionProvider declare that account creation, in it's context, is
allowable even if anonymous account registration is disabled.
Bug: T345185
Change-Id: Iab3d93a3457e73eff408c1938fbdcb01d8be9a7a
Found via (?<!IDBAccessObject)::READ_
We are planning to deprecate and remove implementing IDBAccessObject
interface just to use the constants.
Bug: T354194
Change-Id: I89d442fa493b8e5332ce118e5bf13f13b8dd3477
