The Striker service currently includes support for creating new Developer accounts as part of its signup workflow for Toolforge. Some steps in this workflow are currently powered by calls to Action API endpoints on wikitech.wikimedia.org. This was done historically to avoid reinventing solutions that MediaWiki handles well such as checking usernames for potential spoofing and checking IP addresses against shared block lists. As Wikitech is phased out as the primary Developer account management platform, it would be ideal if Striker could be updated to consume similar services provided by Bitu.

Current MediaWiki API use cases in Striker:

• Is this IP address blocked?
  • Check a provided IP address against block lists to see if it has been banned from creating accounts.
  • Current implementation uses action=query&list=blocks
  • Desired results:
    • Is the IP blocked? (True/False)
    • Reason for block if blocked
  • When used:
    • Validation condition for being allowed to use the account registration wizard
    • Validation condition for being able to use the OAuth SUL account linking feature

• Can this username be created?
  • Check a user proposed Developer account name (cn) or shell account name (uid) against account block lists, account anti-spoof lists, and any other rules about valid usernames to see if it would be allowed if immediately submitted.
  • Current implementation uses action=query&list=users&usprop=cancreate
  • Desired results:
    • Can a new user be created with this name? (True/False)
    • Canonicalized version of the given name (MediaWiki title case)
    • Error message explaining why if user cannot be created
  • When used:
    • Real-time validation of account and shell account names entered into registration form
    • Post-submit validation of account and shell account names entered into registration form
    • Real-time validation of tool name entered in tool creation form. (A "tool" in this sense is the user+group pair created to own the files and processes associated with operating a compute service on Toolforge. These accounts are in the ou=servicegroups,dc=wikimedia,dc=org subtree of the LDAP directory.)
    • Post-submit validation of tool name entered in tool creation form

Additional API opportunities

Today Striker directly adds new Developer accounts to the backing LDAP directory. This includes business logic like setting the expected objectClass attributes and computing the uidNumber that the account should be assigned. This action could be farmed out to Bitu if there was a web API that Striker could use to attempt to create the account and get an acknowledgement or error message on failure.

Input data:

• Shellname (uid)
• Username (cn)
• Email address (unvalidated)
• Password (plain text or hashed depending on API need; current code sends plain text password to LDAP for hashing and storage)
• SUL account name
• SUL account id