Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
<?php
|
|
|
|
|
|
2024-02-16 19:35:21 +00:00
|
|
|
namespace MediaWiki\Tests\Api;
|
|
|
|
|
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
use MediaWiki\Tests\Unit\Permissions\MockAuthorityTrait;
|
2024-03-26 15:04:36 +00:00
|
|
|
use MediaWiki\Tests\User\TempUser\TempUserTestTrait;
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
use MediaWiki\User\TempUser\TempUserCreator;
|
2024-03-26 15:04:36 +00:00
|
|
|
use Wikimedia\Timestamp\ConvertibleTimestamp;
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @group API
|
|
|
|
|
* @group Database
|
|
|
|
|
* @group medium
|
|
|
|
|
*
|
2024-02-16 18:04:47 +00:00
|
|
|
* @covers \ApiAcquireTempUserName
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
*/
|
|
|
|
|
class ApiAcquireTempUserNameTest extends ApiTestCase {
|
|
|
|
|
use MockAuthorityTrait;
|
2024-03-26 15:04:36 +00:00
|
|
|
use TempUserTestTrait;
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
|
|
|
|
|
public function testExecuteDiesWhenNotEnabled() {
|
2024-03-26 15:04:36 +00:00
|
|
|
$this->disableAutoCreateTempUser();
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
$this->expectApiErrorCode( 'tempuserdisabled' );
|
|
|
|
|
|
|
|
|
|
$this->doApiRequestWithToken( [
|
|
|
|
|
"action" => "acquiretempusername",
|
|
|
|
|
] );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testExecuteDiesWhenUserIsRegistered() {
|
2024-03-26 15:04:36 +00:00
|
|
|
$this->enableAutoCreateTempUser();
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
$this->expectApiErrorCode( 'alreadyregistered' );
|
|
|
|
|
|
|
|
|
|
$this->doApiRequestWithToken(
|
|
|
|
|
[
|
|
|
|
|
'action' => 'acquiretempusername',
|
|
|
|
|
],
|
|
|
|
|
null,
|
|
|
|
|
$this->mockRegisteredUltimateAuthority()
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testExecuteDiesWhenNameCannotBeAcquired() {
|
|
|
|
|
$mockTempUserCreator = $this->createMock( TempUserCreator::class );
|
|
|
|
|
$mockTempUserCreator->method( 'isEnabled' )
|
|
|
|
|
->willReturn( true );
|
|
|
|
|
$mockTempUserCreator->method( 'acquireAndStashName' )
|
|
|
|
|
->willReturn( null );
|
|
|
|
|
$this->overrideMwServices(
|
|
|
|
|
null,
|
|
|
|
|
[
|
|
|
|
|
'TempUserCreator' => static function () use ( $mockTempUserCreator ) {
|
|
|
|
|
return $mockTempUserCreator;
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
);
|
|
|
|
|
$this->expectApiErrorCode( 'tempuseracquirefailed' );
|
|
|
|
|
|
|
|
|
|
$this->doApiRequestWithToken(
|
|
|
|
|
[
|
|
|
|
|
'action' => 'acquiretempusername',
|
|
|
|
|
],
|
|
|
|
|
null,
|
|
|
|
|
$this->mockAnonUltimateAuthority()
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testExecuteForSuccessfulCall() {
|
2024-03-26 15:04:36 +00:00
|
|
|
ConvertibleTimestamp::setFakeTime( '20240405060708' );
|
|
|
|
|
$this->enableAutoCreateTempUser( [
|
|
|
|
|
'genPattern' => '~$1',
|
|
|
|
|
] );
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
|
|
|
|
|
$this->assertArrayEquals(
|
2024-03-26 15:04:36 +00:00
|
|
|
[ 'acquiretempusername' => '~2024-1' ],
|
Handle collisions from SerialProvider::acquireIndex
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
2023-12-13 22:56:29 +00:00
|
|
|
$this->doApiRequestWithToken(
|
|
|
|
|
[
|
|
|
|
|
'action' => 'acquiretempusername',
|
|
|
|
|
],
|
|
|
|
|
null,
|
|
|
|
|
$this->mockAnonUltimateAuthority()
|
|
|
|
|
)[0],
|
|
|
|
|
true,
|
|
|
|
|
true
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
