Commit graph

3 commits

Author SHA1 Message Date
Reedy
75640200fb tests: Namespace api tests
Bug: T357823
Change-Id: I0d7cc2c9b166d5e5b913c1305f7cee017fe377af
2024-02-18 15:47:04 +00:00
Reedy
85396a9c99 tests: Fix @covers and @coversDefaultClass to have leading \
Change-Id: I5629f91387f2ac453ee4341bfe4bba310bd52f03
2024-02-16 22:43:56 +00:00
Dreamy Jazz
3b3f1d7851 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-21 14:49:42 +00:00