Why:
To facilitate the evaluation of conditions not directly
"known" by the lookup, eg: owned by extensions
What:
- Add ConditionalDefaultOptionsAddCondition hook which
runs before instantiating ConditionalDefaultsLookup allowing
to add conditions for evaluation in the $extraConditions
array.
- Evaluate the configured conditional default against the
extra added conditions after evaluation of "known"
conditions.
Bug: T376918
Change-Id: Ife6f96397eafd61fdb40528aac315ddde1ef2774
Why:
* When temporary accounts are disabled, no new temporary
accounts should be created either on edit or through
a CentralAuth autocreation.
* UserNameUtils::isUsable is used to prevent the
CentralAuth autocreation making the temporary account
username not usable for login or account creation.
* However, this check to determine if the name is
reserved by the temporary user system still considers
the name as a valid temporary account if the system
was once enabled (but since disabled).
* This is a bug, and instead if the feature is disabled
the username should be considered unusable. This then
prevents the CentralAuth autocreation on a wiki which
knows the feature but has it disabled.
What:
* Update UserNameUtils::isUsable to return false if
the name is reserved by the temporary user system
and TempUserConfig::isEnabled returns false.
* Test this new behaviour with a unit test.
Bug: T370513
Change-Id: I467c39538796a660a7417397c99928a1a25007bc
Why:
* When temporary accounts are known, the match patterns need to
be available. If no match patterns are set, the match pattern
is set to an array containing the generate pattern. Therefore
the generate pattern must also be available if temporary
accounts are known.
* This was not the case before this commit, and certain settings
caused an error to be thrown from isTempName.
What:
* Use the generate pattern for the match patterns if temp accounts
are known and no match patterns are set.
* Update the tests to use a generate pattern but no match pattern
(the same as the default config).
Change-Id: Iadfbed40b14378a9309e8d7afab6064e25480514
Why:
- We want to distinguish temp account creation being enabled from a
configuration state where MediaWiki knows about temp accounts
existing (and can identify and manage them accordingly) while temp
account creation is disabled
What:
- Introduce a 'known' configuration flag to TempUserConfig
- If 'enabled' is set to true, then 'known' is automatically overridden
to true
- If an administrator wishes to disable temp account creation after
temporary accounts have been created, the administrator should set
'enabled=false' and 'known=true'
Co-authored-by: Tchanders <thalia.e.chan@googlemail.com>
Co-authored-by: Kosta Harlan <kharlan@wikimedia.org>
Bug: T356524
Change-Id: I4ce534a847461230f7fa276a565bdc1d6c9857e1
Why:
- Using TempUserConfig is more flexible as it doesn't require us to know
about the internal details of the AutoCreateTempUser config object
What:
- Use TempUserConfig service instead of loading the AutoCreateTempUser
object
- Remove properties from ApiQuerySiteInfo that don't already have
getters. If someone has a need for more this information to be exposed
in ApiQuerySiteInfo, they can be added in a separate patch
- This seems compatible with the goals of T335532 which was about
making it possible to discover via the API if an action would result
in a temp account
- Implement __toString for Pattern, so that it can be used in
ApiQuerySiteInfo
Bug: T335532
Change-Id: Ica84b3e9b9865b8b83a9e9e513c99cd2e47661c9
I don't think these do anything with the documentation generators
we currently use. Especially not in tests. How are tests part of a
"package" when the code is not?
Note how most of these are simply identical to the namespace. They
are most probably auto-generated by some IDEs but don't actually
mean anything.
Change-Id: I771b5f2041a8e3b077865c79cbebddbe028543d1
* Deprecate and stop using $wgBlockTargetMigrationStage. Remove
block_target migration code.
* Make the $schema parameters to DatabaseBlockStore methods default to
SCHEMA_BLOCK. Avoid passing these parameters where possible.
* Remove cleanupBlocks.php
* Deprecate DatabaseBlock static methods which try to present the old
schema for b/c.
Bug: T362133
Change-Id: I845bad8cc09a4528fef46a6f9d490ebdec881d99
Migrate from ipblocks to block/block_target and drop the ipblocks
table. Update tests.
In PostgresUpdater, change some schema update functions to skip field
updates if the table doesn't exist, by analogy with
DatabaseUpdater::modifyField.
Bug: T346293
Change-Id: Icf91b35f7f729cead7c800429653eb30731762a1
Adds two new conditional user option default conditions CUDCOND_ANON and
CUDCOND_NAMED, for the purpose of allowing the specification of a
separate default user option for logged-out users. We're taking two
different approaches to the targeting of logged-out users (anon vs
named) because of the temporary users project - anon will not include
temporary users while named will allow us to target only fully created
user accounts. This will be ultimately be used for the rollout of the
reading accessibility settings menu
Bug: T360098
Change-Id: I316d231330159770f05234dd2f5fdb7d07531002
* Add a comment explaining why we need table aliases in HideUserUtils
subqueries.
* Use the table aliases consistently in inner field references. While
this does not appear to be strictly necessary, since unprefixed fields
refer to the inner query by default, it helps to improve the clarity
of the code.
Change-Id: Id68684ea12060a259dc87e66edd63b925da2c3b1
* As a hardening measure, add a couple different types
of IP range validation to UserNameUtils::isValid. Such
username patterns are often blocked on Wikimedia wikis
via Title_blacklist, but not every MediaWiki operator
has implemented such validationi, and it is trivial to
just add this to core.
Bug: T358535
Change-Id: Ib05bcc8568ad4158b97a5073ccc47baeb304bec1
The idea is similar to the one behind TempUser\Pattern::toLikeValue(),
which has been effectively deprecated by allowing multiple patterns.
Change-Id: Iddb284bff21355deb8ceaa6925d3c2aea34d727e
This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
It has been already announced: https://w.wiki/9DAX
Bug: T354194
Change-Id: Ic2357634b8385d65b55db2b557191419b06c40e0
This commit refactors the LocalizedNumericSerialMappingTest to make
use of mocks for Language and LanguageFactory. Introduced a data
provider for comprehensive testing of getSerialIdForIndex with various
scenarios. Added testConstruct to verify constructor functionality
and LanguageFactory integration. This refactor changes the base test
class from MediaWikiIntegrationTestCase to MediaWikiUnitTestCase,
shifting focus to unit testing.
Change-Id: I00d80d0a1d6d0bb8f7fc5c6e7c6fa4732ef04abb
Why:
* Following T345578, the ActorStore throws an error on
attempting to create an actor whose name is their IP address
if temporary accounts are enabled.
* For the specific case of importing old revisions, we need to
be able to create new actors whose name is their IP address,
while still generally disallowing it.
What:
* Add $allowCreateIpActors flag to ActorStore, and check for
it during actor name validation.
* Set the flag from ActorStoreFactory::getActorStore depending
on whether temporary users are enabled.
* Add ActorStoreFactory::getActorStoreForImport, which sets
flag to true.
* Add RevisionStoreFactory::getRevisionStoreForImport, which
uses getActorStoreForImport. Use this from classes handling
imports, so that IP actors can always be created.
* Add $forImport flag on ActorMigration, since RevisionStore
uses an actor store obtained via ActorMigration.
Bug: T354207
Change-Id: I0715bd0d23089fd8156e579913e6e823089809be
Why:
* The TempUserConfig::getMatchPattern method was deprecated in
7f588780a0 with a replacement of
TempUserConfig::getMatchPatterns.
* All existing usages on WMF deployed extensions have been replaced
so a call to wfDeprecated can be added.
What:
* Add a wfDeprecated call in RealTempUserConfig::getMatchPattern.
The other implementation of this method calls this method, so
this is the only call needed.
* Update the tests to expect the deprecation of ::getMatchPattern.
Depends-On: I122f001ab24e879a573b19468d642b8f579d1024
Bug: T354619
Change-Id: I74ea85429d083737c325c978e1cad04beb6a9325
Why:
* There is a need to update the generation and match pattern on
WMF wikis to a new format that includes the year and starts with
`~`. As such, the 'matchPattern' key needs to be updated.
* Removing the old 'matchPattern' from the wgAutoCreateTempUser
config currently leaves existing temporary accounts as no longer
recongnised as temporary accounts.
* Instead, the 'matchPattern' needs to be able to take an array of
string patterns so that old patterns can still be used for matching.
What:
* Update the MainConfigSchama to indicate that 'matchPattern' in the
wgAutoCreateTempUser config can be an array of strings.
* Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig::
getMatchPattern. This is needed because ::getMatchPattern was typed
to only ever return one Pattern, which is no longer the case with this
config change.
* Update the RealTempUserConfig to support multiple patterns defined in
the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method
returns the pattern or first pattern if multiple are defined to allow
time for existing usages of this deprecated method to be updated.
* Update the RealTempUserConfig to rely on other methods instead of checking
object property values where possible (e.g. use ::isEnabled instead of
checking $this->enabled) to allow easier unit testing.
* Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig
::getMatchPatterns instead of ::getMatchPattern.
* Update mediawiki.util/util.js to be able to parse the 'matchPattern' value
when it is an array of strings.
* Update maintenance/userOptions.php to use ::getMatchPatterns instead of
::getMatchPattern.
* Add and update unit and integration tests for the new code, as well as
expanding coverage over existing code that was indirectly affected.
Bug: T354619
Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
Why:
Sometimes, it is necessary to have different behavior
for newly registered and existing users. For example,
this happens in the Echo or GrowthExperiments extensions.
As of now, this behavior is implemented by inserting
user_properties rows in onLocalUserCreated.
Over time, this results in a singificant amount of rows
inserted, which contributes to the user_properties table bloat,
which is already overly large (cf. T54777). This patch makes it
possible to remove such rows by supporting conditional defaults
for user properties.
What:
Add support for conditional defaults of user properties. This can be
configured via `ConditionalUserOptions` config option.
Bug: T321527
Change-Id: I1549c3137e66801c85e03e46427e27da333d68e2
Why:
* Part of a temporary user name is generated from an index that
increments, which is stored in the database.
* As specified in T345855, the index will be restarted each year.
* Also specified in T345855, the year will be included in
generated temporary user names.
What:
* Since the year must be included in the name in order to avoid
naming conflicts if the index is restarted each year, both are
implemented together and controlled by a single config.
* Add a new config option that, when true, restarts the name
generation index at the start of each year and add the year into
the user name: $wgAutoCreateTempUser['serialProvider']['useYear']
* Add a uas_year column to the user_autocreate_serial table, which
is unique in combination with uas_shard, so the index can be
stored for each shard/year combination.
* The year is added into the username just after the prefix, as
specified in T345855. This is based on research that having the
year near the start of the name aids understanding that the
names are not IP addresses. The position of the year within the
name is therefore not configurable (though whether to include
it is). See T345855 for the research.
Bug: T349494
Bug: T349501
Depends-On: I6b3c640a4e74f52fd4a4f46de5a2cbe80fe3b665
Change-Id: If51acb3f4efa361ce36d919c862a52501a5a7d24
Why:
* Naming conflicts may arise on autocreation.
* For example, when generating temporary user names, the config
wgAutoCreateTempUser['serialMapping']['type'] determines how
the unique, numerical part of the name is generated, and naming
conflicts may arise when changing types.
* Specifically we encountered the case of changing the
$wgAutoCreateTempUser['serialMapping']['type'] from 'scramble'
to 'plain-numeric'.
* In general conflict could be avoided in 'plain-numeric' mode if
the highest number used in an existing username is known, by
adding an offset.
What:
* Handle an 'offset' config option in PlainNumericSerialMapping to
allow avoiding conflicts.
Bug: T353545
Change-Id: Id2f9a5b5cc808ce859b93b597cf7ea0efcd9e269
This would happen due to an offset being configured too large so
can be fixed by changing the config.
Change-Id: Ie572a64e33322ce310bab09406db260fc27a6833
Changes to the use statements done automatically via script
Addition of missing use statements and changes to docs done manually
Change-Id: Ib326ae1e5c8409a98398c721e8b8ce42c73bd012
With multiblocks the user might be hidden even if bl_deleted=0 in the
block row being formatted.
So:
* Add a subquery with a second block_target/block table which determines
whether the user is deleted.
* When formatting each row, redact the name if it is deleted and the
authority does not have permission to see it.
* Add a parameter to show which block is the one responsible for
deleting the user.
* Similarly add a subquery in ApiQueryBlocks.
Change-Id: Id9900397618e1f626802ada6fe4ee4ad10f32495
Follow-up to I9822eb1553870b876d0b8a927e4e86c27d83bd52,
I missed the Static class in that patch.
Bug: T352284
Change-Id: I42653491c19dde5de99e0661770e2c81df5d7e84
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Support migration stages when reading and writing blocks.
I tried to set it up for an easy next stage, in which support for the
old schema is removed. I tried to avoid factoring out of shared code
between the two schemas, so that the old schema cases can simply be
deleted without the need to revert unnecessary abstractions.
However, I added HideUserUtils to factor out ipb_deleted queries. Code
review showed that this was already quite complex, with multiple
approaches to the problem, so it benefits from refactoring even without
the schema abstraction.
HideUserUtils is a service rather than a standalone class to support
unit tests, since unit tests do not allow global config access. When
the migration stage config is removed, it will be a service with no
constructor parameters -- an unnecessary abstraction which should
ideally be resolved at that time.
When interpreting result rows, it is possible to share code by using
field aliases. But when constructing WHERE conditions, the actual field
names need to be used, so the migration is more intrusive in
ApiQueryBlocks and SpecialBlockList, where complex conditions are used.
Bug: T346293
Bug: T51504
Bug: T349883
Change-Id: I408acf7a57b0100fe18c455fc13141277a598925
Why:
Temporary accounts introduced as part of IP Masking are supposed
to expire 1 year after their registration. Accounts can have
multiple registration timestamps when in a wiki-farm setup,
depending on which wiki we consult.
To implement the account expiration logic, we need to know the global
(first) registration timestamp.
Similar to CentralIdLookup, a concept of a registration date
provider is introduced. Unlike IDs, users can have multiple
kinds of registration dates (Wikimedia recognizes local and global,
but third parties can have different needs). For that reason,
any number of registration providers can be registered at any
given time; caller determines which one is requested. The default
is `local`, which is the only provider that is guaranteed to exist.
What:
* Add UserRegistrationLookup
* Add UserRegistrationProviders config variable
Bug: T344694
Change-Id: If9fa12a392064dd504590a861a175e3604a34fab
If a username matches $wgAutoCreateTempUser['reservedPattern'], but the
username is not a valid temp user, return false from
UserNameUtils::isUsable().
This makes reserved patterns analogous to $wgReservedUsernames, and
provides a simple way to reject central sessions for temp users on wikis
where temp users are disabled.
Bug: T342475
Change-Id: I1d7f843e71e605fccf3de93fd145ff43e396619f
