Why:
* When a temporary account is created on edit, no log entry is
visible on Special:Log to indicate that the temporary account
exists.
* No log is specifically set through the call to AuthManager
::autoCreateUser having the $log parameter set always to false.
This was set in e8dbf5f80c which
was the commit that created the code to create temporary accounts.
* No specific reason was provided to not create a log and
in T357498 there is a request to add this log.
What:
* Remove the `false` argument for $log to AuthManager
::autoCreateUser in TempUserCreator::attemptAutoCreate.
* Update the integration tests to verify that an autocreate log is
added when a temporary user is successfully created.
Bug: T357498
Change-Id: Icf6be65a91437aa32684769c2858262a06ad0416
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:
- In real world usages, both the Throttler and request objects are
required. We can override these objects in tests easily enough and
simplify the application code in the process.
What:
- Make Throttler and WebRequest objects required in
`TempUserCreator::create()`
Depends-On: I13cb0dbeaa78e3ad5c7250c7565ee97099d97867
Change-Id: I5eaa68b8212570b3324a0fdec452189c6b56f810
Why:
- We don't want to allow unlimited acquisition of temp account names.
These should be rate limited in similar way to how we limit the
creation of temp accounts
What:
- Provide a TempAccountNameAcquisitionThrottle, and use it in the
acquireName() method
- Set a default that is 10 times the limit of
TempAccountNameCreationThrottle
Depends-On: If660aad1d0f04f366414084aff3f88484a19d416
Bug: T343101
Change-Id: I99d5973498a89ac227847de5837c0a8e895c28fb
The idea is similar to the one behind TempUser\Pattern::toLikeValue(),
which has been effectively deprecated by allowing multiple patterns.
Change-Id: Iddb284bff21355deb8ceaa6925d3c2aea34d727e
Why:
- The pathway to creating a regular account is different from that of a
temporary account. It makes sense to rate limiting creation of these
two types of accounts at different rates.
What:
- Add a TempAccountCreationThrottle config with a restrictive default
that matches the existing production configuration of
AccountCreationThrottle (6 creations per day)
- Update resetAuthenticationThrottle.php to support resetting the temp
account creation throttle
- For now, not adding an equivalent hook for account creation throttle's
ExemptFromAccountCreationThrottle
Bug: T357777
Change-Id: Ibf36ac96f717107bace6f0a3326f79ed129a1dfe
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:
* 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:
* When using the TempUserCreator::create or ::acquireAndStashName to
get temporary account when the chosen username already existed, that
temporary account is treated as if it doesn't exist. This causes
confusing "userexists" errors and also causes the user to be logged
into an already existing temporary account.
* Furthermore, because the user existence check in AuthManager::auto
CreateUser only checks the local wiki, if an existing temporary
account exists globally but not on the local wiki then the code
sign a new user into an existing temporary account.
* This is very bad behaviour, though shouldn't happen unless the
serialMapping configuration uses a SerialMapping class that could
provide duplicates and/or the configuration has been changed to
use a different SerialMapping class.
* There is a need to change the SerialMapping class in use to a
different class, which means that the code will attempt to use
temporary account usernames which already exist.
* As such, the code that is generating the temporary account usernames
based on the SerialMapping and SerialProvider should be aware that
it may produce an already existing temporary account username, even
if the SerialMapping class being used is asserted to never provide
duplicates.
* Therefore, the code that generates temporary account usernames
should always attempt to verify that a automatically generated
temporary account name does not already exist on the wiki.
What:
* Update TempUserCreator::acquireName to check to see if the username
it generates already exists centrally using the CentralIdLookup.
If it does, then the method returns null. Otherwise, the username
that hasn't been used yet is returned.
* Create the private method TempUserCreator::attemptAutoCreate that
attempts an autocreate for a temporary account name, and optionally
logs the account in.
* Update TempUserCreator::create to use ::attemptAutoCreate to
first to check if the account can be created and then again once
the account is created to actually login to that temporary account.
This is done to prevent logins to existing temporary accounts on
the local wiki. The second call to actually perform the login is
necessary as there is no other way to login to a temporary account.
* Update TempUserCreator::acquireAndStashName to respond to the changes
to ::acquireName, such that it returns null if ::acquireName returns
null and also does not modify the session.
* Update EditPage::maybeActivateTempUserCreate to return a Status and
return a good status in all cases except when a temporary account
name could not be acquired.
* Add IEditObject::AS_UNABLE_TO_ACQUIRE_TEMP_ACCOUNT, and use it as
the value of the fatal status returned by EditPage
::internalAttemptSave if a temporary account name could not be
acquired. This will cause the display of a useful error to the
user on edit.
* Update ApiEditPage and ApiAcquireTempUserName to die with an error
if a temporary account username was unable to be acquired.
* Provide tests for the untested ApiAcquireTempUserName.php file
including testing the new behaviour.
* Add and update tests for TempUserCreator.php
Bug: T353390
Change-Id: Id3a316ea0eba544d51d4ffcdfb03e35f4b3c54cc
Why:
To inform temporary users about their account expiring
10 days before it is effectively expired.
What:
- Add optional int `notifyBeforeExpirationDays` to $wgAutoCreateTempUser,
for setting how many days before account expiration should users be notified
- Add AutoCreateTempUser config to the tempUserBanner script to use
config values for the popup alerting text logic
- Set the popup default state to open when temp user needs to be notified
- Disable the auto-close option for the popup so users need to
explictly dismiss it.
Bug: T344694
Change-Id: I530e911733c9822d6308ce92fafd425e50942d43
Why:
Temporary accounts (introduced as part of IP Masking)
are supposed to expire 1 year after their registration.
Automatic account expiration can be done via a maintenance
script, which would be periodically executed via cron / systemd.
Make it possible for extensions to provide their own logic
for generating a list of temporary accounts to invalidate.
This is used in CentralAuth to base registration timestamp
on the global registration timestamp.
The default behavior is "temporary accounts do not expire",
given the feature requires a maintenance script to run
periodically, which will not be the case on third party
instances.
What:
* Add `expireAfterDays` to $wgAutoCreateTempUser, controlling
how many days temporary accounts have.
* Add UserSelectQueryBuilder::whereRegisteredTimestamp(),
filtering accounts based on user_registration.
* Add ExpireTemporaryAccounts maintenance script, which is
@stable to extend.
Bug: T344695
Change-Id: If17bf84ee6620c8eb784b7d835682ad5e7afdfcc
This was done automatically using the
`Universal.WhiteSpace.CommaSpacing` sniff, which will be included in the
next release of the MW PHPCS config.
Some of these have been adjusted manually where the autofix broke
vertical alignment.
Change-Id: I54a4668d8a2759b9d7de47742c943a535a04e211
Why:
There are extensions that need to check a handful of
users for temp-ness at once (such as GrowthExperiments).
This is not really possible as of now (it would be necessary
to call UserIdentityUtils::isTemp several times, which can get
slow for large bulks of users).
What:
Add TempUserConfig::getMatchPattern() that can be used
to generate a LIKE database condition.
While at it, this patch also adds named() and temp() to
UserSelectQueryBuilder.
Bug: T341389
Change-Id: I90b5c59462c5c98bf5dcf9fa15d20553ef6599a5
I found myself needing to just get the stashes name without the
placeholder for T331397, and I thought that this seems like a weird
API. The caller should get the placeholder separately if desired,
which is easy to do in all of the current callers.
Follow-up to 65f04c763a.
Change-Id: Icf1d24f17b60a461ef682bc5da01be6ebc3a2d93
For pst on parse/compare/editstash/(all)revisions/(all)deletedrevisions
Do not show the IP when IP masking is enabled,
instead show a previous aquired temp name or a placeholder on preview.
MediaWiki itself used this for the ajax preview on GUI's action=edit
Cannot acquire a new unsaved temp user as api parse does not persist
the global session (each request results in a new id)
and it would require a db write on a read request.
Bug: T331397
Change-Id: I74bb4d655f371bd99e3b618d1a0ac45d730c746c
Split concepts of "match pattern" and "reserved pattern". Add config
"reservedPattern" which specifies a username pattern to be denied for
creation, but unlike matchPattern, it does not immediately flag all
accounts with such names as temp accounts. This can be used before
migration or after rollback to safely prevent creation of conflicting
accounts.
* Add TempUserConfig::isTempName(), which does what isReservedName()
previously did, i.e. determines if a name is a temp username.
* Make TempUserConfig::isReservedName() return true if the name matches
either the match pattern or the reserved pattern.
* UserNameUtils::isTemp() continues to determine whether a username is
actually a temp username.
* Add UserNameUtils::isTempReserved() as a proxy for
TempUserConfig::isReservedName()
Bug: T307064
Change-Id: I26755731fad89530a06824181106cd7b4e077d9e
Add a mapping function which converts sequential integers to a sequence
in which most of the digits change each time, but without significantly
increasing the length.
Change-Id: I1011a96894fbf0b92d20a96149e68014f53e3c3c
Add services and utilities for automatic creation of temporary user
accounts on page save, in order to avoid exposing the user's IP
address.
* Add $wgAutoCreateTempUser, for configuring the system
* Add TempUserConfig service, which interprets the config.
* Add TempUserCreator service, which creates users during page save as
requested by EditPage. With proxy methods to TempUserConfig for
convenience.
* Add table user_autocreate_serial. Table creation is necessary before
the feature is enabled but is not necessary before deployment of this
commit.
Bug: T300263
Change-Id: Ib14a352490fc42039106523118e8d021844e3dfb
