Architecture:MediaWiki/user management domain

MediaWiki Architecture
Structure
Technical layers Domain modules Pattern language Subsystems Flows Practices
Domain modules
content reuse domain (dumps, etc) customization domain (gadgets, site css, etc) curation domain (protect, delete, tag, etc) monitoring domain (technical) navigation domain (skin, etc) notification domain discovery domain (search) federation domain abuse prevention domain (block, protect, filter, etc) accountability domain (history, logs, contributions) content rendering domain access control domain (permissions, groups) content editing domain user management domain (create, rename, login) internationalization domain content representation domain maintenance domain ontology modeling domain (wikibase) (not in core) campaigns domain (banners and such) (not in core) communication domain (flow) (not in core)

The user management domain is concerned with the handling of user accounts, sessions, and settings.

Other domains this domain depends on:

• TBD

Some domains using this domain:

• access control for permission checks
• abuse prevention for blocking

Layers:
This domain has components in all layers.

Location:
Files belonging to this domain do not currently have a dedicated location in the namespace or file system structure. They may in the future be collected under the UserManagement namespace.

Status:
As of May 2020, the user management domain is heavily entangled with the rest of the system via the prolific User class. Other components belonging to this domain, like the AuthManager and the Session object, are better isolated.

Examples:
The AuthManager class is an example for a component from the user management domain.

Vocabulary survey

This is a rough survey of essential nouns and verbs that belong to the domain, providing a preliminary vocabulary. The survey is guided by existing code, but also includes nouns and verbs found to be missing.

Nouns:

• Session: exists, should become a data object in the value layer. Accessed from other domains for various reasons.
• User: heavily entangled, much too big, should be replaced with UserIdentity.
  • UserIdentity is also needed in the content representation domain. Should these be shared or translated?
• Account: same as UserIdentity?
• Settings: should be factored out of User. Needed by other domains.

Verbs:

• create user: covered by includes/specialpages/LoginSignupSpecialPage.php and AuthManager, should become a command.
• log in: covered by LoginSignupSpecialPage and AuthManager, should become a command or be handled by a service object.
• log out: covered by LoginSignupSpecialPage and AuthManager, should become a command or be handled by a service object.
• update settings: covered by User, should be handled by a service object.