Core Platform Team/Initiative/Authority/Initiative Vision

From mediawiki.org
Jump to navigation Jump to search

< Authority

Vision:
  • The principal authorizing an action is clearly modeled and readily available in code.
  • Developers can check user permissions in a concise and clear way.
  • Permission checks or rate limits applied by application logic can easily be tested.
Theme: Code health (decoupling)
Stakeholdr(s):
  • MediaWiki developers (core and extensions) will benefit from clearer, more testable code
  • The security team should be consulted to make sure the design is conceptually sound.
  • Quality + test engineering may be interested since we are making code more testable by removing the need for global state.
  • The Performance team should be consulted to ensure the proposed implementation is sound.
Problem:
  • We currently rely on PermissionManager to perform permission checks.
  • PermissionManager currently relies on global state to access information required to determine whether an action should be allowed (such as the web request and user session).
  • Having the caller pass in that information as a parameter is not feasible, since the caller can and should not know what information the permission check is based on.
  • We are lacking a mechanism to inform asynchronous jobs about what authority they run under, beyond a user account. restrictions based on OAuth grants or IP address are not enforced in jobs.
  • The User object in some situations mixes information from the current web request with information for other users. There currently is no component that encapsulates the information relevant to permission checks.
Solution:
  • Introduce a concept called "Authority" that models a principal's authority to perform an action. It encapsulates logic for performing permission checks, combining information about the user account with information about the current request and session, accounting for things like blocked IPs, OAuth grants, and rate limits.
  • Provide different implementations for use in different situations (e.g. for the current user's session, for an async job, for a maintenance script, for temporarily elevated permissions of automated operations, etc)
  • Authority instances are provided to and associated with application code in the same way this code currently gets a User object. This makes migration straight forward without the need for big structural changes.
Aligned Goals:
  • Improve code quality by reducing coupling
  • Improve code health by improving testability
  • Improve maintainability by modeling domain concepts clearly